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
-
"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
You are asking Microsoft to be user friendly? I knew you were a glass half full person!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
"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
Been there. I was upgrading a project to newer versions of .NET Framework, ASP .NET MVC and the cascade of packages that needed to be updated when I ran into this. It is quite a manual task to figure out where the problems are and how to solve them. The promise of freeing us from DLL hell, well, I am still waiting for that to be fulfilled.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
-
"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
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
-
"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
What you need here is the Fusion Log Viewer fuslogvw.exe in your .NET Tools folder, of course.:confused: 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. X|
-
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
With VS2008 you just didn't hear about them :laugh:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
"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
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 -
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
-
"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
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
-
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
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; -
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
-
"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 -
Been there. I was upgrading a project to newer versions of .NET Framework, ASP .NET MVC and the cascade of packages that needed to be updated when I ran into this. It is quite a manual task to figure out where the problems are and how to solve them. The promise of freeing us from DLL hell, well, I am still waiting for that to be fulfilled.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
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
-
"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
Tools ⇒ Options ⇒ Projects and Solutions ⇒ Build and Run Set both "MSBuild verbosity" options to "Diagnostic". (I seem to recall that the one that sounded obviously right had no effect, so try both. Oh, and "Detailed" doesn't work; it has to be "Diagnostic".) Then trawl through 500+ pages of output to see if you can find some hint as to what the problem might be. Then make some changes that might fix the problem, until the next time you start Visual Studio, when the same error will come back again. Finally, give up, go and grab a beer, and learn to suppress your OCD and put up with this warning appearing in the build output on every build until the project is obsolete. :-D
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
"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
I'm pretty darn sure that looks like MSBuild output as Visual Studio doesn't actually do the build. It's important to blame the right team ;)
-
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
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
-
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, 2013How 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? :doh: 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
-
Gary Wheeler wrote:
and the new solution never exhibited the error.
Yup. I ended up replacing the entire directory (sln, csproj's, etc). 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
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; -
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
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
-
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
raddevus wrote:
A very cryptic tool, as I said up there
I read that. :) Now the only problem is, how the heck am I going to remember this gem of wisdom as associate with the problem, and know where I put your wisdom for future reference, where the future could be a long time from now, in a galaxy far far away. ;) 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
