I am seeing these errors during builds.
C:\Program Files (x86)\Microsoft WCF Data Services\5.6.4\bin\.NETFramework\Microsoft.Data.Services.Client.xml' contains invalid characters.
C:\Program Files (x86)\Microsoft WCF Data Services\5.6.4\bin\.NETFramework\Microsoft.Data.OData.xml' contains invalid characters
C:\Program Files (x86)\Microsoft WCF Data Services\5.6.4\bin\.NETFramework\Microsoft.Data.Edm.xml' contains invalid characters.
C:\Program Files (x86)\Microsoft WCF Data Services\5.6.4\bin\.NETFramework\System.Spatial.xml' contains invalid characters.
I dont get them locally when I run MsBuild with the same arguements, and I can even run MSBuild on the private build agent just fine too.
I have other projects using OctoPack just fine, and using these packages. I am going to double check them very carefully because the other ones work just fine.
The problem is solved by upgrading the affected packages from 5.6.4 to 5.7.0 (current latest build).
I spent a good couple of hours trying to figure this out. I figured I could save others the time by posting a question I would have asked, and the answer too.
Also make sure that the App.config/web.config of your main target also has binding redirects:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Services.Client" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.7.0.0" newVersion="5.7.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.7.0.0" newVersion="5.7.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.7.0.0" newVersion="5.7.0.0" />
</dependentAssembly>
You may have these in a service/utility project within your solution, but if they are not present in the main config file of your "deployable" target, they will be ignored and you might still pick up references to
C:\Program Files (x86)\Microsoft WCF Data Services\5.6.4
Versions of the DLLs, and not the NuGet packaged versions you intended, from your "packages" folder.
Related
After downloading ASP.NET MVC 5.x template, I update the connection string, restore NuGet packages and then try to run Update-Database command in Package Manager Console, but I consistently get the following error:
Could not load file or assembly 'Castle.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I was able to solve this once by removing all packages and adding them back one at a time, but this is extremely time-consuming.
I have had this same experience with both the Angular and Multipage versions, and I am using VS2017 Community.
What am I doing wrong?
in the Web project's web.config it reads:
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
You can remove that binding redirect.
We have TFS build machine configured to build source code from TFS. On this machine we had Team Foundation Server 2013 together with Microsoft Build Tools 2013 installed and then recently, we installed Microsoft Build Tools 2015. In the build defintion, we put /tv:14.0 for MSBuild arguments to indicate we want to use version 14.0 of MSBuild. Also, we set the perform code analysis to be false so that it won't perform code analysis.
However, when we queue a build, it failed with given errors:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.targets (214): The source file for this compilation can be found at: "C:\Users\tfsservice\AppData\Local\Temp\b54ca1bb-e696-4214-a196-5c79c32345cd.txt"
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.targets (214): An error has occurred during compilation. error CS1705: Assembly 'Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' uses 'Microsoft.Build.Framework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'Microsoft.Build.Framework, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.targets (214): The "SetEnvironmentVariable" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files (x86)\MSBuild\14.0\bin\amd64" directory.
Does anybody experience this issue before?
It seems like the Microsoft.Build.Utilities.Core was referenced to the incorrect version of Microsoft.Build.Framework.
However, in MSBuild.exe.config, this assembly is redirected corectlly
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
</dependentAssembly>
Any helps are appreciated.
P.s. The solution we want to build is a visual c++ solution upgraded from VS 2013 to VS 2015.
Seems that many other community members have the similar issue, the /tv:14.0 argument doesn't work. Check this link for the detailed information.
The workaround is: instead of using the /tv:14.0 argument, you need to customize the tfs build process template to set ToolPath of the Run MSBuild for Project to target to MSBuild14; and set ToolVersion to "14.0".
I moved a project from MVC 3 to MVC 4 a while ago now.
when I build, I get the messages
1> No way to resolve conflict between "System.Web.Mvc, Version=3.0.0.0 ..." and , Version=2.0.0.0
1> Consider app.config remapping of assembly "System.Web.WebPages ..." from Version "1.0.0.0" to Version "2.0.0.0" to solve conflict and get rid of warning.
1> Consider app.config remapping of assembly "System.Web.WebPages.Razorfrom Version "1.0.0.0" [c:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies\System.Web.WebPages.Razor.dll] to Version "2.0.0.0" [C:\Users\OEM\documents\visual studio 2012\Projects\DabTrial\packages\Microsoft.AspNet.WebPages.2.0.30506.0\lib\net40\System.Web.WebPages.Razor.dll] to solve conflict and get rid of warning.
and so on.
When I look at references, they are all the later versions, and the web.config only refers to the later versions. When I search the entire solution directory by the public key token (in windows explorer) I find no XML type files with references to the earlier versions.
obviously the path to the files is different, but I cannot find where the compiler is being directed to the path for the earlier .dll file.
The project builds and runs fine, but I assume the compiler is suggesting these changes for a reason. Thanks for any help.
Your nuget dependencies are probably referencing the MVC3 version. You can try putting the following into your web config to force the MVC4 version:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
You could also try running the following in the Package Manager Console
Update-Package -Reinstall
You have to have at least version 2.1 of nuget for this command but it will update your packages and retarget them if you have updated .NET. You can check this post for more information.
Retargeting solution from .Net 4.0 to 4.5 - how to retarget the NuGet packages?
I also had such problems. I did just two things:
updated System.Web.Mvc and all dependencies to the last version (5.2.3)
Rebuild all solution (I did using "Solution -> Clean Solution", then "Solution -> Build Solution")
Try setting AutoGenerateBindingRedirects to true in the project file.
I have published the project on Azure websites and it throws exception:
Microsoft.SqlServer.Types, Version=11.0.0.0 missing when I try to
run report. Locally everything works fine. I have
RepowrtViewer.WebForms and ReportViewer.Common both version 11.0.0.0
in the project. On the machine locally in SDK/Assemblies
I have Microsoft.SqlServer.Types, Version=11.0..2100.6. I have tried to add this to the project but did not work. The same exception,
Where do I find Microsoft.SqlServer.Types 11.0.0.0?
Thank you
You're probably referencing the DLL's from the global assembly cache on your local machine but they aren't present in the GAC in Azure.
Open up visual studio and right click on the Microsoft.SqlServer.Types assembly reference in your project and select properties. Change the copy local flag from False to True and recompile your application. You should now have the the Microsoft.SqlServer.Types.dll file in your applications bin folder.
Redeploy to azure and hopefully the error will have vanished.
How I got this solved.
I had to add 5 files altogether and I moved these 5 files to my bin directory. I then added these references by browsing to the bin directory and adding them. I rebuilt my project and copied to web server - all working fine.
Microsoft.SqlServer.Types.dll (make sure you copy the correct version as I had sql 2008 but using report viewer 11)
Microsoft.ReportViewer.ProcessingObjectModel.dll
Microsoft.ReportViewer.Common.dll
Microsoft.ReportViewer.WebForms.dll
Microsoft.ReportViewer.WinForms.dll
Also make sure you have the correct version of these dll's from the GAC in the bin directory and I installed report viewer on the server. These are the steps that worked for me.
The best solution would be to install the Microsoft.SqlServer.Types NuGet package.
PM> Install-Package Microsoft.SqlServer.Types
And follow instructions from its readme.htm
I had exactly the same issue but found the solution quite quickly. It was using the Assembly within this folder C:\Program Files (x86)\Microsoft SQL Server\100 where I then removed my reference via Visual Studio and referenced the right file from within this folder C:\Program Files (x86)\Microsoft SQL Server\110
If you still need this reference then please make use of this method.
Cheers,
Check your SQL server ProductVersion using the following query,
SELECT
SERVERPROPERTY('MachineName') AS ComputerName,
SERVERPROPERTY('ServerName') AS InstanceName,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel;
GO
It will be like something this,
You can see in my case ProductVersion = 13.0.1601.5. In your project go to NuGet package manager and search Microsoft.SqlServer.Types. From there you can see, Microsoft.SqlServer.Types with the same ProductVersion and Install it.
My Experience
I used to face this kind of problems until I understand the GAC and Bin deploy
Your computer has all the installed DLLs into a place called GAC (Global Assembly Cache). so your local programs can search for their needs in there if they can not find the required DLL in the execution path. It's often work for developer itself, but when you deploy your program to the client, problems may appear.
Remember that, you can always Bin deploy your DLLs. first, go to the references tree in your project and add the required Dll by browsing your GAC (usually c:\windows\assembly\GAC_MSIL...) then go to the property window of the added Dll and set Copy Local to True . Now you can publish or deploy your project and be sure that it will works.
Make sure you are not missing a binding redirect
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Types" publicKeyToken="89845dcd8080cc91" culture="neutral" />
<bindingRedirect oldVersion="10.0.0.0-11.0.0.0" newVersion="14.0.0.0" />
</dependentAssembly>
https://www.microsoft.com/en-us/download/details.aspx?id=56041
Download from here if this needs to be installed in your machine
I'm try to build project that use LinqToExcel library. Additionally, I'm use log4net to write logs.
My problem started when I'm tryomg to run this lines of code:
var excel = new ExcelQueryFactory(ExcelPath);
return (from r in excel.Worksheet<RowDetails>(company.Name)
select r).Count();
This line thrown exception:
ERROR MyProj.Program Main:System.IO.FileLoadException: Could not load
file or assembly 'log4net, Version=1.2.11.0, Culture=neutral,
PublicKeyToken=669e0ddf0bb1aa2a' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040) File name: 'log4net,
Version=1.2.11.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a'
It's important to note that I'm successful to use log4net before this line.
I would appreciate any help.
Thanks a lots!
As marc_s pointed out, this problem usually appears when trying to load different versions of the same assembly. Make sure, that your project uses the same assembly version as the LinqToExcel library, which is also dependent on log4net. Also any other libraries should use the same assembly version. To solve the issue, you can also try to use assembly redirect in your app.config like so:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a" culture="neutral" />
<bindingRedirect oldVersion="1.2.10.0" newVersion="1.2.11.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
try to install it using nuget
Install-Package log4net -Version 2.0.0
Version 2.0.0 is for log4net 1.2.11
I'm having similar problem. I think that the problem is in LinqtoExcel referencing Log4Net version 1.2.11, and you have referenced Log4Net sepratly and you get latest 1.2.13 version. In build output you'll end up with 1.2.13, and when LintoExcel calls Log4Net it expects 1.2.11 and error ocures.
I got this issue after upgrading log4net through NuGet, only to find that the newer version was signed with a different key.
You can grab the 'oldkey' version from the apache log4net site and then it worked for me.