Thanks for nothing Visual Studio
-
"Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed." Either they aren't actually listed or they are buried so deep as to be invisible. To the devs who wrote this pointlessness: If you can see there's a conflict why not list it then and there? What about: "Found conflicts between different versions of the same dependent assembly "Assembly.dll (1.2.3.4)" and "Assembly.dll (1.2.3.5)" that could not be resolved." There - was that hard?
cheers Chris Maunder
That's not that terrible of an error message. It's trying to tell you what you need to do to fix the issue. Although if I remember correctly they changed what level of logging was required to get the assembly load information. I got this exception the other day "Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints" from calling "EndLoadData" on a DataTable. Which constraint caused an issue? Which column? Which row? Who knows. The exception was coming from DataSet.EnableConstraints() which gets called by DataTable.EndLoadData(). I tried to use .NET source stepping but it wouldn't load DataSet.cs for some reason. Looking up the function in the .NET reference source I saw that the function loops through all constraints on a table and tries to enable them. Instead of throwing an exception when it found a constraint it couldn't enable it just kept a flag saying that one of the constraints had an error and then at the end it checks that flag and throws an exception if its true. At that point it no longer knows what constraint caused an issue. I ended up copying code out of the reference source to recreate the function and using reflection to call internal methods so I could find out which constraint and which column had the error. After that it was easy to fix.
-
Hi Chris, Can you tell us which version of VS you are using? I think I have seen something like
Chris Maunder wrote:
"Found conflicts between different versions of the same dependent assembly "Assembly.dll (1.2.3.4)" and "Assembly.dll (1.2.3.5)" that could not be resolved."
in VS2015.
I am not the one who knocks. I never knock. In fact, I hate knocking. Just barge in will'Ya?
VS 2017.3 It's to do with the nuget breaking changes and MS moving nuget system packages back into the framework. Evidently they will provide some guidance on this issue. Maybe.
cheers Chris Maunder
-
That's not that terrible of an error message. It's trying to tell you what you need to do to fix the issue. Although if I remember correctly they changed what level of logging was required to get the assembly load information. I got this exception the other day "Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints" from calling "EndLoadData" on a DataTable. Which constraint caused an issue? Which column? Which row? Who knows. The exception was coming from DataSet.EnableConstraints() which gets called by DataTable.EndLoadData(). I tried to use .NET source stepping but it wouldn't load DataSet.cs for some reason. Looking up the function in the .NET reference source I saw that the function loops through all constraints on a table and tries to enable them. Instead of throwing an exception when it found a constraint it couldn't enable it just kept a flag saying that one of the constraints had an error and then at the end it checks that flag and throws an exception if its true. At that point it no longer knows what constraint caused an issue. I ended up copying code out of the reference source to recreate the function and using reflection to call internal methods so I could find out which constraint and which column had the error. After that it was easy to fix.
Wearwolf wrote:
f I remember correctly they changed what level of logging was required to get the assembly load information
Even at "diagnostic" level there's no information I can find. The point is you shouldn't have to do anything: they have the info, it's a potentially serious issue, so just spit it out and tell us, please.
Wearwolf wrote:
just kept a flag saying that one of the constraints had an error
Wow. That's insanely lazy.
cheers Chris Maunder
-
Ya' know, I didn't have all of these problems I here of with VS2008.
"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
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
-
I have had to spend days cleaning up the resulting mess that such issues cause and have had to re-install my entire Windows once on account of discrepancies between framework versions and Visual Studio. In both cases it was found to be a problem with the commercial release builds of Visual Studio. What happens is that you install Visual Studio with let's say framework version 4.6.1 with a certain identifying set of identifiers for the version but there are multiple versions of each framework level. Then you install an application that also requires 4.6.1 but has a different version of the same exact framework. Guess what? Visual Studio blows up worse than a hydrogen bomb. What is left in its wake is a corrupted system that cannot be cleaned out properly. The only way to do this is to re-install the OS or get a good tech-rep at Microsoft who knows what they are doing to help you clean up the mess. The first time my tech-rep and I were able to clean up the mess after three days of continuously working with each other. The second time I figured it would take as much time to simply do a re-install of the Windows OS. As a result of these experiences I cannot release my products with the capacity to install a version of the .NET Framework for fear that it may destroy a developers Visual Studio installation.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
:omg: Great. The other option I was thinking was just moving up to 4.7 and seeing if that confused things a little more...
cheers Chris Maunder
-
I have had to spend days cleaning up the resulting mess that such issues cause and have had to re-install my entire Windows once on account of discrepancies between framework versions and Visual Studio. In both cases it was found to be a problem with the commercial release builds of Visual Studio. What happens is that you install Visual Studio with let's say framework version 4.6.1 with a certain identifying set of identifiers for the version but there are multiple versions of each framework level. Then you install an application that also requires 4.6.1 but has a different version of the same exact framework. Guess what? Visual Studio blows up worse than a hydrogen bomb. What is left in its wake is a corrupted system that cannot be cleaned out properly. The only way to do this is to re-install the OS or get a good tech-rep at Microsoft who knows what they are doing to help you clean up the mess. The first time my tech-rep and I were able to clean up the mess after three days of continuously working with each other. The second time I figured it would take as much time to simply do a re-install of the Windows OS. As a result of these experiences I cannot release my products with the capacity to install a version of the .NET Framework for fear that it may destroy a developers Visual Studio installation.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Steve Naidamast wrote:
The second time I figured it would take as much time to simply do a re-install of the Windows OS.
This is why I resorted to running my dev environments in disposable VMs years ago. If I anticipate performing an action that will break the environment I make a copy of the VM, take the action and if it explodes I revert to the backup VM. Saved my bacon many times while configuring Windows XP and VS-2005 for Windows CE 6.0 kernel development. It's sad to have to operate this way but in reality has saved me tons of time I would've spent rebuilding development environments over the years.
-
Steve Naidamast wrote:
The second time I figured it would take as much time to simply do a re-install of the Windows OS.
This is why I resorted to running my dev environments in disposable VMs years ago. If I anticipate performing an action that will break the environment I make a copy of the VM, take the action and if it explodes I revert to the backup VM. Saved my bacon many times while configuring Windows XP and VS-2005 for Windows CE 6.0 kernel development. It's sad to have to operate this way but in reality has saved me tons of time I would've spent rebuilding development environments over the years.
I believe quite a few developers are using this option. However, my machine is a little slow for such alternatives so I use VMs merely to test the installation of my projects against different operating systems. Visual Studio has gotten so bloated as a result of the attempt to be everything to everyone it is now causing a lot of its own issues. They should have left Visual Studio as a base product with WinForms, WPF, and ASP.NET WebForms. Everything else should have simply been an additional option for the developer to select when he or she was ready to install it. If I remember correctly, the install of Visual Studio 2015 has about 6gigs to go through with little filtering of development types.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
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
-
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.
-
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 X| 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
Latest Article - Class-less Coding - Minimalist C# and Why F# and Function Programming Has Some Advantages Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Gosh! That sounds like debugging Javascript.
We're philosophical about power outages here. A.C. come, A.C. go.