The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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.
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.
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.
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.
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
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.
where the future could be a long time from now, in a galaxy far far away
That really is a great summary of the situation.
File it under, "things I need to remember, when I've fallen down a deep dark crevasse and cannot seem to remember".
You have to use this thing about once every 1 or 2 years.
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 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.
Sr. Software Engineer
Black Falcon Software, Inc.
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.
Sr. Software Engineer
Black Falcon Software, Inc.
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.
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.
just kept a flag saying that one of the constraints had an error