The "MSBuild.ILMerge.Task" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'System.Compiler, Version=3.0.0.0, Culture=neutral, PublicKeyToken=736440c9b414ea16' or one of its dependencies. The system cannot find the file specified.
NuGet ilmerge from version 3 also includes System.Compilers.dll file (besides ILMerge.exe), so if you used version 2 and only copied ILMerge.exe to some other place for later use, now you need to copy System.Compilers.dll as well
The Nuget package for MSBuild.ILMerge.Task (version 1.0.5) states:
MS Dynamics CRM users: merging in Microsoft.Xrm.Sdk may crash your plugin, exclude it from the merge with Copy Local=false.
An additional article I found says that this assembly (and a few others) should be excluded (they used a picture in their article, hence the screenshot rather than a quote):
Perhaps try excluding Microsoft.Xrm.Sdk (and maybe the other two .DLLs if you are using them) from the merge as stated.
Related
I am new to windows desktop application development.
I have created an application using visual - studio 2010 in which I have used one form for data entry. One form with report viewer control and a report(.rdlc) file which report is drawn.
My problem is that I want to make my application compatible for dot net framework 3.5. To do that, I have changed the target framework to 3.5 from the 'Advanced Compile Options...' from the project properties. But I am getting the error when I run the application after changing the target framework to 3.5 is :
Could not load file or assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Line 123, position 5. C:\Users\Amir\Desktop\Bill_System\Bill_System\Bill_System\My Project\Resources.resx Billing_System
How to tackle this error?
Please help. Thanks in advance.
It is a ratty problem with resources, as you can tell from the exception message, they also take a dependency on the framework version. Which is not changed by just changing the target version of your project.
Open the Resources.resx file in a text editor, Notepad will do. Search for "4.0.0.0" and change that to "2.0.0.0". That might not fix the problem, some resources are binary serialized and embedded as a base64 encoded string in the .resx file. You'll easily recognize them as a long string. You'll need to fix those with the Visual Studio resource editor, remove them and add them back.
You are referencing the System.Drawing assembly for the framework 4.0 (as you can read from the error) and not for the 3.5
You have to locate your System.Drawing reference and change it to 3.5.
The easiest way is to:
Open you Project
Go to Solution Explorer
Expand the Reference group
Delete the System.Drawing reference
Right click on the Reference group
Add Reference
On the ".NET" tab, search for System.Drawing to add the right reference
You got the following error:
"Could not load file or assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Line 123, position 5."
This error is occur due to incorrect path to the .dll of system.drawing assembly,the following 2nd line surely work for you.
OW please find the path in your system.
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Drawing.dll" related to your system
[Void][System.Reflection.Assembly]::LoadFile("C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Drawing.dll")
I had to rebuild the Krypton.Toolkit.dll from it's source in order to remove a license error message on runtime. In the references I have removed and replaced the old Krypton assemblies with the ones from source.
I am now getting the error: (and a related cast type error)
Could not load file or assembly 'ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e'
I understand the error message. Although the my new reference has the same name it does not have a strong name at all, so there is no PublicKeyToken.
What I don't understand is why it's still looking for the old PublicKeyToken when the reference is being replaced completely? This DLL is not in the GAC.
At first these DLLs with matching PKT where referenced in my main projects .csproj file. I gave my two assemblies a strong name and replaced the old references.
I have then cleaned and rebuilt the project and the new strong name has been replaced in the csproj file. However Visual Studio is still looking for a87e673e9ecb6e8e in the aforementioned project, as shown in the error window.
Sorted.
A reference was referencing the same 3rd party DLL as my project and they where conflicting.
Something in your solution seems to still hold a reference to the strong-named version.
You can open your .csproj (or I think .vbproj if you're doing VB) and look for that reference in your favorite text editor. Look for a line similar to:
<Reference Include="ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e, processorArchitecture=MSIL">
</Reference>
Searching for the PublicKeyToken is probably sufficient.
If you find it, you will know which project still references the strong named version.
You may see a sub node like
<Reference ... >
<HintPath>..\SomePath\ComponentFactory.Krypton.Toolkit.dll</HintPath>
</Reference>
directing the linker to look in a specific path to resolve the reference.
You can manually edit the project file (back it up first), or use that knowledge to update the reference through VS if you're more comfortable with that.
UPDATE
If it turns out (as it did in this case) that the issue is with a referenced DLL that in turn references the other Krypton version, a good tool for diagnosing the issue is the Fusion Log Viewer
http://msdn.microsoft.com/en-us/library/e74a18c4.aspx
Note that Fusion Log Viewer must run as Administrator. If not, it will not show any results but will otherwise not complain.
I am working on setting up a buildserver for our team.
Background
We are using Microsoft Visual Studio 2010 Ultimate. Our product contains C# code(mainly), external DLL’s and C code. We are working with .Net 4.0 and have more than 70 projects.
We are working with 3 branches of our code:
Production branche(what is currently released)
Test branche(hot fixes, bug fixes, end user testing)
Development branche(adding new fetures)
All the branches are under TF source control.
Goal
What we want is to have a build server to build and run all the unit tests for all the branches once a day, the build server should use the code in the source control. Our goal is to have some fast standard error detection. We would prefer as little to no maintaining of the build server.
We are not going to use the builds the buildserver produce, all we want is to use the build server to continuously to build and unit test our branches.
What is set up
There are currently set up two the build definition, one for the Test Branche and one for the Development Branche, both build definitions taking the code from the source control(that part works all good), but here is where the fun begins.
Problem
The Test Branche can build and run unit tests all fine.
The Development Branche cannot build due to an(or like 5 of) errors:
The type or namespace name 'XXX' does not exist in the namespace 'YYY' (are you missing an assembly reference?)
The error is for project X refereing to project Y. Both project X and Y is C# .Net 4.0 projects and we have fully control over both of them, both X and Y is compiled to DLL’s. Project Y contains a Interface the classes in project X are implementing.
The annoying detail is there is no difference in the Test Branche and Development Brance for either project X or Y. The two projects have been fully identical the last 3 month.
So the question is, why does it work in the Test Branche but not in the Development branche?
I have tested:
- The projects are correctly refered to each other.
- All 3 Branches have no problem building on my own / any of my co-workers development machines(we have tested on 5 different machines).
- I have tried to delete the whole X project and recreate it, didn’t work.
- I have tried to delete the whole Y project and recreate it, didn’t work.
- I have tried to change the namespace for project X project and its classes, didn’t work.
- I have tried to change the namespace for project Y project and its classes, didn’t work.
- (I have even restarted my development machine)
- All the changes have always been checked into the source control where after the buildserver was set to build.
Extra information
I have been digging around in the logging files and found some interessting details, this is for the details of building project X in the Development Branche
Task "AssignProjectConfiguration"
Project reference "..\..\A" has been assigned the "Debug|x86" configuration.
Project reference "..\..\Y" has been assigned the "Debug|x86" configuration. (can see there is a project Y)
Project reference "..\..\B" has been assigned the "Debug|x86" configuration.
But then in the Task ”ResolveAssemblyReference”
Task "ResolveAssemblyReference"
TargetFrameworkMoniker:
.NETFramework,Version=v4.0
TargetFrameworkMonikerDisplayName:
.NET Framework 4
TargetedRuntimeVersion:
v4.0.30319
Assemblies:
System
System.Xml.Linq
System.Data.DataSetExtensions
Microsoft.CSharp
System.Data
System.Xml
System.Core
AssemblyFiles:
C:\Builds\1\A
C:\Builds\1\B
(----- Missing project Y -----)
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
Where in the Test Brance for the same task
Task "ResolveAssemblyReference"
TargetFrameworkMoniker:
.NETFramework,Version=v4.0
TargetFrameworkMonikerDisplayName:
.NET Framework 4
TargetedRuntimeVersion:
v4.0.30319
Assemblies:
System
System.Data.Entity
System.Xml.Linq
System.Data.DataSetExtensions
Microsoft.CSharp
System.Data
System.Xml
System.Core
AssemblyFiles:
C:\Builds\1\A
C:\Builds\1\B
C:\Builds\1\Y (There it is)
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
So it feels like it for some reason just ”forgets” the reference from project X to project Y.
Help
I had the same problem.
It took me few hours to find out that in this case the problem was not my fault :-)
http://support.microsoft.com/kb/2516078 :
This issue occurs due to a bug in the Path.GetFullPath in .NET Framework library.
This is a known issue in Visual Studio 2010
Symptoms:
... when you try to build a solution with multiple
projects where there exists dependency relationships among them, in
specific conditions a build fails with the following error message.
Error Message:
“C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
(1200, 9): warning: The referenced project 'Relative path to the
referenced project from the current directory’ does not exist.”
A build fails with the error message above when the following
conditions are met.
You have a solution with multiple projects where there exists dependency relationships among them.
The sum of the following two path length is exactly added up to 259 characters (= MAX_PATH – 1)
1) The path of a referencing project’s directory. 2) The relative path
to a referenced project from the current directory (= a referencing
project’s directory).
NOTE: MAX_PATH is the maximum path length defined by Windows API and
is set to be 260 characters.
Workaround:
To work around this issue, you can change path length and make sure
that the sum of the following two path length is NOT added up to 259
characters.
The path of a referencing project’s directory.
The relative path
to a referenced project from the current directory (= a referencing
project’s directory).
I encountered the same error recently. The solution built locally in VS2010 just fine, but consistently failed on the build server. In the end, the MSBuild definition was set to the Release x86 configuration, but the complaining project referenced an assembly in bin\x86\Debug, instead of bin\x86\Release.
Verifying the release version of the assembly was referenced instead of the debug version (and correcting as needed) seemed to do the trick for me.
The problem on my end was entirely different unfortunately.
I was building two different versions of the same common code, one for .Net4 and another for Silverlight 5, with the same file name (.Framework.dll).
Since the build server outputs everything to the same folder by default, the Silverlight version of the assembly ended up overwriting the .Net4 one because msbuild decided to build it later. This caused a problem as soon as the next project in the solution was built, which was dependent on some classes that were available on the .Net4 version of the dll, but not on the Silverlight one.
I ended up splitting the projects in multiple solutions and setting the 'Solution Specific Build Outputs' option to true on the build definition 'Process' tab.
I had a very similar issue. I found that in the Configuration Manager, under the Release Configuration, the platform was set to Any CPU and the Build checkbox was not checked.
Setting the platform to x86 (as all my other projects are set to this for legacy reasons) and making sure the project was set to Build under this configuration fixed my issue.
I've just had a similar issue and it ended up being the developer who last worked on the code decided to add references to some dlls in the obj\debug directory.
It is a bit old question but I've just come across similar issue and in my case it was the wrong referenced project Id (let's call it B) in the .cproj file of the project that was failing (project A). Originally, I copied the project A from another solution and included it in the solution I am working with now. The referenced project B was also present in both solutions so Visual Studio automatically resolved references even though in the A's .cproj referenced project B was still pointing to the B in the solution I copied it from:
<ProjectReference Include="..\B.csproj">
<Project>{F3006530-D421-4A89-AA8B-376DBAA31E03}</Project> - wrong Id!
<Name>ProjectB</Name>
</ProjectReference>
Weirdly, Visual Studio would ignore the incorrect Id and presumably use the path only so there were no build errors and correct dll would appear in project A's bin. MSBuild on my build server wouldn't be that liberal though.
To fix it you can either edit .cproj file in a text editor or simply remove references and add them back making sure they're in your current solution.
A have a large web service solution (written in C# targetting .NET 3.5) which is comprised of 16 individual projects (many class libraries, a few web applications and setup projects). It is developed in visual studio 2010.
I was recently experimenting with Microsoft.CodeContracts, and after evaluating it decided that it was not suitable for my needs. I removed all of the code that referenced it, and removed the assembly references from all of the projects that referenced it.
However my web service has now started to randomly return this error message:
"Could not load file or assembly 'Microsoft.Contracts, Version=1.0.0.0, Culture=neutral, PublicKeyToken=736440c9b414ea16' or one of its dependencies. The system cannot find the file specified."
How/Why can it still be trying to load that assembly when I have removed all the code & references to it?
On investigating further, I am still finding that Microsoft.Contracts.dll is showing up in the /bin/ folder of my web application, even though no projects reference it. It is also listed as a "detected dependency" in my setup project - but I am 100% certain NONE OF MY PROJECTS ARE USING IT!
This is driving me absolutely nuts - there is obviously something lurking around thats holding the reference. How can I remove all traces of Microsoft.CodeContracts from my solution?
There are numerous XML elements within CSharp project files that start with CodeContracts.
Remove them if you feel you need to do so.
There will be as many sections as you have configurations {Release, Debug} x {Any CPU, Mixed Platforms} = 4. Do this for each *.csproj file in your solution.
Keep in mind that CodeContracts conditionally generate/weave code, so you app might behave differently.
In my project file, I have the following entry:
<Reference Include="Microsoft.Practices.Unity, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\..\Libraries\Microsoft.Practices.Unity.dll</HintPath>
</Reference>
which in absolute terms translates to:
C:\dev\LUT600 2.1.1\OCC600\Libraries
Somehow, when I try to compile the project, Visual Studio loads a reference from a totally different path:
/reference:"C:\Program Files\Microsoft Enterprise Library 4.1 - October 2008\Bin\Microsoft.Practices.Unity.dll.
How it resolves to this location is a complete mystery as this DLL is not referenced anywhere in this project.
I have set Specific Verion to true but it still resolves the reference from this location.
Any ideas?
TIA.
Klaus
It may be that the reference does not have the same version number as the assembly in that particular location, so it starts searching elsewhere to find a "better" match.
Rather than just taking the file you specified, VS always uses a probe path to try to find referenced assemblies. This often provides a random "pick anything with the same name" effect. On our build server I once found 996 copies of an assembly. 995 were the same, correct version, and one was the wrong version. And one day our build stopped working when for no apparent reason it suddenly decided to use the single wrong copy!
Try deleting and recreating the reference. That often helps.
In the worst case scenario, delete all copies of that assembly from your PC, except the version you wish to link to. (if possible without destorying anything you hold dear)
You most likely added the reference from the GAC(Global Assembly Cache). The long list of references that take a while to load are references from the GAC. Try removing your reference, and re-adding it by browsing to that assembly in the Add References dialog.
It could be finding the dll in the Search Path before it evaluates the HintPath. As mentioned in this post, there are two places that are searched before HintPath.
Files from the current project – indicated by {CandidateAssemblyFiles}.
$(ReferencePath) property that comes from .user/targets file.