Develop Reference

ASP.NET web site builds locally, but throws MSB3268 on the build server

I added a project to my web site solution. Everything built fine locally and on the build server.
I added a line in web code to call a method in the new project. Everything built and worked fine locally, but it broke the build on the build server.
I got a pile of errors going something like this:
warning MSB3268: The primary reference "C:...\ProjectName.dll" could not be resolved because it has an indirect dependency on the framework assembly "Assembly.Name (e.g. System.Runtime)", Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.5". To resolve this problem, either remove the reference "C:...\ProjectName.dll" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
After all the warnings, the build failed with an error indicating the namespace ProjectName could not be found. Makes sense considering the project's dependencies couldn't be resolved.
At first I wondered if there was an issue with targeting the wrong framework. But there was a mix of 4.0 and 4.5 projects referenced by the 4.5 website. This was the first one that had failed.
The only difference between this and the other projects was that it referenced third-party DLLs. So apparently their dependencies are the ones that couldn't be resolved.

This post held the key: http://devsilos.blogspot.com/2014/10/msb3268-while-targeting-aspnet-web-site.html
The author suggests:
aspnet_compiler for some reason does not take into account the .dll-s that reside under the Facade directory of 4.5 assemblies (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\Facades).
It looks only under
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5
My extrapolation on that idea is that maybe the compiler doesn't take into account DDLs in the Facades directory if they're referenced by a third-party DLL rather than directly from your project.
The solution, as suggested by the author, was to find the DLLs matching assemblies mentioned in the MSB3268 warnings and copy them from Facades to its parent directory.
I think my problem/solution differed from the blog's in that it had nothing to do with the .NET Framework version targeted. It had only to do with whether the build server's compiler looked in the right places to resolve third-party DLLs' dependencies.
The problem caused about ten hours of frustration. I hope this helps someone else avoid that!

Use .net DLL with broken References

I have to use a DLL as an API in my application (C#, .NET 4.5). I can reference the DLL normaly. No error at all. But if I want to use any class of this DLL, I get the following compile error:
Error CS1705 Assembly 'Assembly_X' with identity 'Assembly_X,
Version=12.3.0.0, Culture=neutral, PublicKeyToken=c878e80841e75d00'
uses 'Assembly_YY, Version=65535.65535.65535.65535, Culture=neutral,
PublicKeyToken=c878e80841e75d00' which has a higher version than
referenced assembly 'Assembly_YY' with identity 'Assembly_YY,
Version=12.3.0.0, Culture=neutral, PublicKeyToken=c878e80841e75d00'
Then i checked the DLL (Assembly_X) in ILSpy. The Assembly_X has two references to Assembly_YY: One with the version 12.3.0.0 and one with the version 65535.65535.65535.65535.
I tried the "bindingRedirect" in the App.config. But since the error occures during compile time this doesn't help.
I don't have the source code of Assembly_X or Assembly_YY.
How can I use this DLL or repair it?
UPDATE
The developers of the dll finally answered my call for help. The only work around they know of is to use Visual Studio 2013 instead of Visual Studio 2015 or 2017. It seems VS 2013 is not bothered by these double reference at all.
They write, that the error is created by a encrypting tool for the dll.
Thank you all for your ideas and help.

It looks like the first DLL is referencing a library which is a higher version than the other DLL you are using.
so you have 3 DLL's to consider: A, B & Bv2
Your project is referencing A & B
But A references Bv2 (an updated version of B)
SO when you go to use functions of A it throws an error because it finds B instead of Bv2.

The problem basically that you are referencing 'Assembly_X' which references assemblies 'Assembly_YY' versions 12.3.0.0 and 65535.65535.65535.65535 and you referenced only 'Assembly_YY' version 12.3.0.0 in your application and didn't reference 65535.65535.65535.65535
Now according to the problem explanation on Microsoft Docs, and your example which you don't have the source code for the assemblies you have to:
Add a reference to 'Assembly_YY' version 65535.65535.65535.65535 of the DLL to your application to make it compile and to enable the application to run, you can provide an application configuration file that includes a <dependentAssembly> element that uses <assemblyIdentity> and <codeBase> child elements to specify the location of version 12.3.0.0 of the DLL.

You are referencing a higher version of DLL then the one you currently have.
You will need to add the reference to the higher version assembly:
'Assembly_YY, Version=65535.65535.65535.65535, Culture=neutral, PublicKeyToken=c878e80841e75d00'
in order to solve this.
Right now you are referencing
'Assembly_X' with identity 'Assembly_X, Version=12.3.0.0, Culture=neutral, PublicKeyToken=c878e80841e75d0
If this is a downloadable library, search for it in the nuget package manager and download it.
If it's a library written by you, obtain the latest version of the library and add it to your project.

There was a conflict between "mscorlib, Version=4.0.0.0" and "mscorlib, Version=2.0.5.0" [duplicate]

On a new Win8.1 reinstall, with all of my code restored from backup, I'm suddenly now getting a Visual Studio warning when I build the main project of my solution:
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.
I set the Output log level to Detailed and I found a few entries like this:
There was a conflict between "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes". "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it had a higher version.
Trouble is, I'm not referencing mscorlib anywhere in the solution—old or new. I have a couple of apps on my machine that require .NET 3.5, but I can't see how that could be related.
One difference: the old Win8.1 install on which this warning did NOT occur was a standalone machine; this time I'm domain-joined. I don't know whether that makes a difference (I can't see how), but I thought I ought to mention it at least.

Having different versions of a Nuget package on different projects may cause this problem as well. Make sure that all your packages have the same version:
(Within Visual Studio) Right click on the solution
Click on Manage Nuget packages for Solution
Click on the Consolidate tab
For every package in the Consolidate tab, update the package to the same version for every project.

I was able to fix this by issuing an update-package -reinstall command at the Package Manager Console.
BUT
Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong!

I have been able to fix this issue by deleting my ".suo" file of my solution and then re-opening the solution. I then rebuild the solution and the issue is gone.
The ".suo" file is within the ".vs" folder which is what I usually delete.
Good luck!

I solved this by setting my verbosity to Diagnostic as per this answer.
Once I did that and rebuilt my solution, the build log actually listed the specific packages that depend on the two different versions of mscorlib.
In my particular case, my project had references to version 2.0.20126.16343 of System.Net.Http. I opened up the NuGet Package Manager and updated this package to the latest version (4.3.4 at the time). The next time I built my solution, the warnings were gone.

Well my solution is a little bit simpler than all of the above. I simply added a reference to the two Assemblies throwing this error (System.Runtime.Serialization and mscorlib) and rebuilt the project. By doing this, I specified the 4.0.0.0 version and removed the ambiguity.
One of the two (mscorlib) couldn't be added via the GUI because of the "A reference to 'mscorlib' could not be added. This component is already automatically referenced by the build system." error.
I needed to open the .vbproj (.csproj) file and add a reference manually via:
<Reference Include="mscorlib" />

I've tried all the following, but none has resolved the issue.
the command "update-package -reinstall".
Update and package via Consolidate tab.
Removing the ".suo" file.
However, My issue was a different case, I guess the new version of Xamarin.Forms package has used a different version of mscorlib. so I've downgraded it and it works fine.
I suggest you try all above solutions and also try to find which package is conflicting.

Following Memet Olsen's advice using VS2017 community...almost identical:
Right click Solution in Solution Explorer.
Select 'Manage Nuget Packages for Solution'
Check the packages. If any of them have a blue up-arrow rather than a green tick use the 'update' button

I also have tried all of the proposed solution to no avail.
In my project, this warning message was caused by a dll reference having a dependency on a different .net framework than the one that is targeted by my project.
In order to find out which dll reference was causing the warning, I simply used .net reflector to explore each dll reference to find out which one was referring a different .net framework (mscorlib).
In order to fix the issue, the reference dll has to be updated to a version which targets the same .net framework as the project using it, if such a version exist.
Hope this helps.

Warning: Can't find dll

I have a client program written in C# where one of the projects in the solution handles a case which the machine has SQL 2005 installed.
I have added the relevant DLLs, but I get that warning:
CA0060 : The indirectly-referenced assembly 'Microsoft.SqlServer.ManagedDTS, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' could not be found. This assembly is not required for analysis, however, analysis results could be incomplete. This assembly was referenced by: d:\Any CPU\Bin\Debug\MyProgram.SSIS2005.dll.
According to properties of Microsoft.SqlServer.ManagedDTS it's version is 9.0.3042.0, I don't understand why it requires the version 9.0.242.0.
I don't know if it related, but the version of Microsoft.SQLServer.DTSRuntimeWrap is 9.0.242.0.
What have I tried?
Deleting and adding the reference
Changing manually the version required in the csproj file
I thought about getting all dlls with the same version, but didn't find such a source at the web.
Any Ideas? Thanks, KM
EDIT:
Another details,
My target framework is .Net 4.0
I have set the 'useLegacyV2RuntimeActivationPolicy’ to true

Try to add the reference from:
C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.ManagedDTS
And set the Local Copy for the reference in VS to true, hope this helps.

As far as I know SQL CLR is not currently compatible with .NET 4.0, you should try switching to 3.5 and see is that helps.

Check for the version of the system by going to:
C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.ManagedDTS
If they are different then click on Add reference and follow the link to add the same.
Also in web.config, under the assemblies tag remove the one with the older version.

As #Mightymuke mentioned in the comments, Fuslogvw.exe shows which DLLs were loaded. One of my projects had a reference to DLL that referenced an old version of Microsoft.SqlServer.ManagedDTS.

Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common' or one of its dependencies

I have searched google for this and could not find the solution to the problem.
My Website references DAL (custom dll) which references Enterprise Library Data Access Components.
I have added the Enterprise Library from the NuGet Package Manager and when I try to build the Website this compilation error pops up:
Error 44 Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference
I have tried setting the Copy Local = True in the DAL for the Enterprise Library dlls and the dlls are transferred to the Bin directory of the website along with DAL dll, but still the error pops up.
Can anyone guide me on this....

The problem is that the DLL that you are using and the one that is referenced in your project are different. I'm not sure what the difference in the manifest is, but it could be version and/or public key.
You have a couple of things to try:
Open the properties for the DLL reference in your project and set Version Specific to false.
Remove the reference, delete the DLL from the bin folder, and re-add the reference.
You could also have a different/incorrect version in your GAC. In order to make sure that you are always using a specific, known version create an assemblies folder relative to your project directory, copy the dll to that directory, and add a reference to the DLL in the assemblies directory rather than one in GAC or elsewhere on your machine. This will ensure that only the specific version that you have targeted for the application will be used rather than any version that is updated on your machine at a later time.

NuGet CommonServiceLocator
Install-Package CommonServiceLocator

This dll is likely to be in the GAC on developer machines as part of some windows application installation (my best guesses are Visual Studio or SSMS).
That’s why we are likely to get warnings or errors on the build machine which we try our best to keep the GAC as clean as the production server’s.
To download the file manually, you can go to https://servicelocation.codeplex.com/
To fix the build warnings and errors, you simply need to run a NuGet command to install the CommonServiceLocation package. The package contains only this one dll file. Microsoft has released only 1 version (1.0.0.0) of this file since 2008. The file is fully compatible with all .NET versions and all Unity versions.

I was able to resolve this issue by removing from ALL the Logging references in the app.config file::
, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null
ie:
<section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings,
Microsoft.Practices.EnterpriseLibrary.Logging,
Version=6.0.0.0, Culture=neutral, PublicKeyToken=null"
requirePermission="true" />
Becomes:
<section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings,
Microsoft.Practices.EnterpriseLibrary.Logging"
requirePermission="true" />
This is not ideal, but it does work...
The Enterprise Library Configuration Tool, sets the values back, so you need to watch for that. I know there is a way to tell the config file to accept these mis-matched settings -- but I I am not sure how.

Setting the PublicKeyToken values for each of the EnterpriseLibrary references in Web.Config fixed it for me.

Remove the reference, delete the DLL from the bin folder and VS, and re-add the reference.