|
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
|
|
|
|
|
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
|
|
|
|
|
|
Gosh! That sounds like debugging Javascript.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
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. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
