|
seriously, what's the point of upgrading target in an existing development (unless still very fresh)? If a mature project is happy in say 4.0 it really should be left there and NOT pushed to the new target.
1. avoid these issues
2. keeps installation simple - if got multiple proj's in a solution some not updated then have to install the multiple .net's on older machines
3. it's not as if ms fix anything - they just add more [mostly bloat - even then even older versions can achieve identical results perhaps albeit with a few more lines of code].
And really for the sake of "compatibility" often they can't or shouldn't ever fix some of the "mysterious"/"expected" issues/behaviours... many of their own apps would break if they did that.
Yes [nearly all] exception causing bugs can be fixed, but operating behaviours even if they seem wrong or non standard must never be changed
... imagine if they decided next version of .net would zero base VB arrays (and all the dumb-ass newbie devs quickly open VS and flick projects to the new target?)
In short:
- minimally a waste of time, but in fact
- a very bad practice.
Sin tack
the any key okay
|
|
|
|
|
It was not a mature project. The project was shelved years before and it was decided to dig it up and restart the effort. It is as simple as that.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
I respectfully disagree. 
In my experience, it's often more cost effective to upgrade projects whenever they're in active development.
In part, because the newer toolchains are much easier to develop for. Easy build settings, better CI support, better reporting.
In part, because the old toolchains become obsolete.. and you need people with experience to fix those problems.
But most importantly: management expects everything to work everywhere whenever they feel like it.
Migrating to the most flexible target is always the safest bet.
|
|
|
|
|
I disagree as well. At some point most applications WILL need to be updated. It is far more effective to upgrade the framework or IDE one step at a time, rather than a huge jump when forced by other priorities.
Currently I support an oolldd vendor product. Last year it was still being compiled in Visual Studio 2005, but for various reasons needed to be upgraded. The vendor put in a lot of effort, tried to jump to VS2013, it failed. They had to regroup and compile first in VS2008 and then VS2010. They finally got it into VS2012, then quit as the product is being sunsetted.
At some point all software, including frameworks and compilers/IDEs, become obsolete. The business need for a product doesn't become obsolete, and business priorities and costs may keep a program around long after it should be rewritten. [this vendor product is the poster child!]
My team is writing a replacement. The current plan for the project I'm on is to stay on VS2015 (IDE we started with) until we publish. After that, when major changes need to be made, investigate the current MS IDE to determine if we should upgrade the framework and/or IDE. We probably won't do minor framework changes unless we need to, but major version will get looked at. By being proactive on keeping it current, this program will likely still be running fine 10 years from now.
At some point it will need to be rewritten ... but that's a business decision made above my pay grade. Until such time, we'll keep this puppy in optimal shape to meet the business need.
|
|
|
|
|
Lopatir wrote: it's not as if ms fix anything
At least according to the fix lists they do fix security problems.
|
|
|
|
|
Ya' know, I didn't have all of these problems I here of with VS2008.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
With VS2008 you just didn't hear about them 
|
|
|
|
|
VS2008 is the best version they ever came out with (IMHO) and for any projects I do in my private consulting practice it's still the "go to" environment. I develop mostly desktop and a few web-based applications with it. I'll drive the "wheels" off this one. The executables still run fine in the latest Windows environments and on the web. YMMV (your mileage may vary) but I'd rather not constantly be chasing a moving target. The client cares not what version tool I choose to use, their money spends just as well as it does if I chose to waste my money, time and effort upgrading the technology.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
|
|
|
|
|
As I work with multiple clients, running various servers of various vintages and with a variety of OS versions, I keep VS2008, 2013, 2015 on VMs so that I can update/fix as required without the hassle of talking the IT departments into installing more frameworks.
I also keep a copy of VS2003 up my sleeve but I haven't used it for ages.
For most work I am now comfortably on VS2017 and that is what I use to develop new projects.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
What you need here is the Fusion Log Viewer fuslogvw.exe in your .NET Tools folder, of course.
Isn't it obvious? No.
In the past, found somewhere around --> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
Fuslogvw.exe (Assembly Binding Log Viewer) | Microsoft Docs[^]
This tool allows you to turn on some logging that will tell you which .NET dependency (with version and details) the thing is attempting to bind to.
It's all very cryptic, beginning with the name. Why Fusion Log Viewer?
The original name of the internal Microsoft Project which would become .NET -- and they never renamed the thing. 
|
|
|
|
|
Yes - been using it.
Would be great if it actually (a) gave some insight and not just a 200 line list of events, and (b) actually worked consistently (worked once then no more).
cheers
Chris Maunder
|
|
|
|
|
Yeah, the tool is quite brittle.
Chris Maunder wrote: (worked once then no more)
As I read that I remembered having that issue in the past too. What was it? What was it? Sorry, I just can't remember.
Good luck, hope you get it worked out.
|
|
|
|
|
Oh look...more IE goodness. 
microsoft docs explain problem Note
The Assembly Binding Log Viewer (Fuslogvw.exe) uses the Internet Explorer (IE) cache to store its binding log. Due to occasional corruption in the IE cache, the Assembly Binding Log Viewer (Fuslogvw.exe) can sometimes stop showing new binding logs in the viewing window. As a result of this corruption, the .NET binding infrastructure (fusion) cannot write to or read from the binding log. (This issue is not encountered if you use a custom log path.) To fix the corruption and allow fusion to show binding logs again, clear the IE cache by deleting temporary internet files from within the IE Internet Options dialog.
|
|
|
|
|
I want to echo this sentiment regarding SQL server error messages.
"Syntax error near ')'" sucks bigger'n a bucket of ticks.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
"There was a syntax error somewhere in your query" would be more honest.
cheers
Chris Maunder
|
|
|
|
|
They could add "and it looks like it sucks to be you", and be completely correct
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
How about "String or binary data would be truncated"?
Sure, SQL knows which column is causing the problem. But can it be bothered to tell you, so you can fix your query? 
Please fix the "String or binary data would be truncated" message to give the column name | Microsoft Connect[^]
(Active since 2008; 1524 up-votes; last update from MS was August 2016: "It's still too early to know when such a fix would reach a publicly visible release.")
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's because the company they bought sql server from is out of business and the devs that originally coded it are dead, and there's no comments in the code because the original devs didn't need comments.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Come over to the SSIS side. 
OnError 12:41:57 Data Flow Task:Error: The "ADO NET Source" failed because truncation occurred, and the truncation row disposition on "ADO NET Source.Outputs[ADO NET Source Output].Columns[VM Farm Name]" specifies failure on truncation. A truncation error occurred on the specified object of the specified component.
|
|
|
|
|
Chris Maunder wrote: These reference conflicts are listed in the build log when log verbosity is set to detailed."
Which is like finding a needle in a haystack.
I had that problem with some code at work, related to NuGet packages and the only solution was to create a whole new solution and add references/packages one at a time, and figure out which package was unhappy.
Marc
|
|
|
|
|
Marc Clifton wrote: create a whole new solution and add references/packages one at a time, and figure out which package was unhappy
I've done that before, and the new solution never exhibited the error. I concluded it was one of those order-things-were-added sorts of buggery.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: and the new solution never exhibited the error.
Yup. I ended up replacing the entire directory (sln, csproj's, etc).
Marc
|
|
|
|
|
It could be worse - you could be using Qt Creator. When I was using it on an after-hours job a couple of years ago, I got in the habit of saving a backup copy of their version of project/solution files before I did anything that changed them. Opening a corrupted file would cause Creator to crash, which was the only indicator that the file had been corrupted. Very frustrating, especially when you're adding 50+ source files to a project.
Software Zen: delete this;
|
|
|
|
|
Marc Clifton wrote: Which is like finding a needle in a haystack.
More like finding one specific needle in a giant stack of needles. 
Whenever you find yourself on the side of the majority, it is time to pause and reflect. ~ Mark Twain
|
|
|
|
|
A very cryptic tool, as I said up there ==> The Lounge[^]
But Fusion Log Viewer is relatively easy to run (from a Visual Studio Command prompt) and will tell you immediately upon running your exe the problem it sees:
Microsoft docs says The tool (fuslogvw.exe) displays the following details about the selected bind failure:
* The specific reason the bind failed, such as "file not found" or "version mismatch".
* Information about the application that initiated the bind, including its name, the application's root directory (AppBase), and a description of the private search path, if there is one.
* The identity of the assembly the tool is looking for.
* A description of any Application, Publisher, or Administrator version policies that have been applied.
* Whether the assembly was found in the global assembly cache.
* A list of all probing URLs.
EDIT
Usage
1. Start fuslogvw
2. configure it for the type of output you want (screen, log file, etc)
3. Start your failing app.
4. examine results
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
