MSBuild Using Wrong Version of Assembly to Compile RDLC File - msbuild

I am using the reportviewer control from VS 2010 to create client side reports (rdlc). Everything is working fine on my development machine, and when I manually compile (via VS2010) and manually deploy to a test machine that doesn't have development tools installed.
In order to get the test machine to work (without installing VS2010 or ReportViewer.exe), I had to add references in my project to Microsoft.ReportViewer.Winforms, Microsoft.ReportViewer.Common and Microsoft.ReportViewer.ProcessingModel and have them all "Copy Local".
I have the rdlc files configured for Build Action => embedded resources. This is the default setting when adding a new rdlc to the project. I am open to configuring this otherwise if this would resolve this problem (no idea if its related).
The problem: since adding the rdlc files, the solution no longer builds on the build server. I have installed ReportViewer.exe on the build server, and have verified that the required assemblies exist in the GAC. The .Net 4 framework is NOT installed on the build server--I don't think this is required because the solution targets the 3.5 runtime.
I believe the root of the problem is the following from the build log:
Target "RunRdlCompiler": Building
target "RunRdlCompiler" completely.
Output file
"obj\Release\RdlCompile.compiled" does
not exist. Using "RdlCompile" task
from assembly
"Microsoft.ReportViewer.Common,
Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a". Task
"RdlCompile":
Report\RDLC\GreenReport.rdlc (0,0):
error rsInvalidReportDefinition: The
report definition is not valid.
Details: The report definition has an
invalid target namespace
'http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition'
which cannot be upgraded.
From what I can tell, Microsoft.ReportViewer.Common version 10.0.0.0 is what should be used to "compile" the rdlc, but MSBuild appears to be using 9.0.0.0. I believe if I could force it to use the right version (which IS installed in the GAC), the solution would compile.

This is because your Microsoft.Common.Targets file is pointing to the 9.0 version of the assembly.
If you look in [sysdir]\Microsoft.NET\Framework\v3.5 you will find Microsoft.Common.targets, which is driving a lot of what MSBuild does. This verion of the common targets file points to [Program Files]\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets forcing MSBuild to run with the 9.0 version.
When you installed .NET 4.0, you got a new common targets file in the v4.0.x directory, this new one now points to [Program Files]\MSBuild\Microsoft\VisualStudio\v10.0\ReportingServices\Microsoft.ReportingServices.targets which points to the 10.0 version of the ReportViewer assemblies.
The 10.0 ReportViewer is compiled against .NET 3.5 and intended to work in both 3.5 and 4.0. You could very likely get rid of the .NET 4.0 framework, and alter your 3.5 common targets file to point to the new ReportingServices target file, and it should work. In theory anyway, I've never actually tried it. You may be best off just sticking with 4.0, as that's what we intended when we designed the MSBuild support for the new viewer.

Just install Microsoft Report Viewer 2010 SP1.

I had a very similar issue. Just all of a sudden I could no longer build a VS2010 project that contained an .rdlc file. I wasn't converting any reports or using a report server, everything was local. I tried creating a brand new project and adding an empty new rdlc report and hit build and it wouldn't work. Just one day it stopped compiling and gave me the following error:
The report definition is not valid. Details: The report definition has an invalid target namespace 'http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition' which cannot be upgraded.
Turns out the issue was my "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\ReportingServices\Microsoft.ReportingServices.targets" file had somehow changed. The top of my file was:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
And it should have been:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
I changed that one "Using Task" line in the file and everything builds again. REALLY frustrating and it ate up two days of my life. Hoping posting this comment may help someone else in a similar situation.
Jim Lafler

I have tried re-installing all and it didnt work. Then, I tried updating Microsoft.ReportingServices.targets as per Jim's post but even didnt work for me.
At the end, I just copied Microsoft.ReportingServices.targets from other machine (where it was running without error). And surprisingly, it is working.
The additional difference I noticed while comparing, to change PublicKeyToken along with Version.
This may be the case for me only but Jim's post was much useful.
SFUH

Turns out I did need the .Net 4.0 Framework, and more specifically the 4.x version of MSBuild, which uses the newer version of the Microsoft.ReportViewer.Common library.
So even if you are targeting the 3.5 framework, if you create the rdlc with VS2010 it will expect to be "compiled" using 4.0 tools.

I have the same problem: we using ReportViewer 2012 (version of assemblies starts with 11). Both on local machines and on build machine are installed ReportViewer 2012 package and VisualStudio 2013. On local machines compilation in VS succeeds, but on build machine during queued build MSBuild throws such error:
The report definition is not valid. Details: The report definition has an invalid target
namespace 'http://schemas.microsoft.com/sqlserver/reporting/2010/01/reportdefinition'
which cannot be upgraded.
I tried to modify Microsoft.Common.targets from .NET 3.5 folder in way, that is described in this post, but no effect. Then I opened Microsoft.Common.targets from .NET 4.0 folder, and found there such strings:
<!-- VS10 without SP1 and without VS11 will not have VisualStudioVersion set, so do
that here -->
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)'
==''">10.0</VisualStudioVersion>
</PropertyGroup>
Then I realized that problem may be in incorrect value of variable $(VisualStudioVersion), so I added to build definition in section "Process" this MSBuild parameter:
/p:VisualStudioVersion=12.0
And it worked! Build completed successfully.
Hope this will help someone.

Pasting file paths doesn't seem to be going through... how about this:
Was:
TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.Common, Version=8.0.0.0...
And is now:
TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0...
James

The NetFx40_LegacySecurityPolicy was enabled in my devenv.exe.config, and when I commented this line out, the project built successfully.
We had enabled the legacy security policy on our team to enable our team to work with DevExpress 7.2 controls from within Visual Studio 2010, but in this case, it shows that the approach we took is not always the best.

I lost 2 full days of development due to a similar issue. On building my project it would succeed, but on rebuild it failed with no errors. On investigating the verbose build log in the Output window it directed me towards a problem with the rdlcompile function (so reporting services local report embedding issue). After trying every thing I finally manage to resolve the issue, but disabling my virus scanner. The Antivirus was somehow interfering with my rebuild and caused the rebuild to fail.
After disabling virus scan, rebuild works 100%

I have same problem on my Visual Studio 2013.
The dll version of reporting service on my project is Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
When i checked my ReportingServices targets
C:\Program Files\MSBuild\Microsoft\VisualStudio\v12.0\ReportingServices\Microsoft.ReportingServices.targets
I found the task version is 11.0.0.0
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>
When i changed the task version to 10.0.0.0 corresponding to dll version on my proejct.
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
It' worked.

I just removed this file from my file system. The reports are simply ambedded no need to be compiled.
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\V11.0\ReportingServices\Microsoft.ReportingServices.targets
this worked fine for me and for my build server.

Related

MSBuild Error after upgrading TeamFoundation dlls to 2017

So, we were using 2013 TFS dlls in our projects (namely TeamFoundation.Client, TeamFoundation.VersionControl.Client, and TeamFoundation.Common). I recently upgraded the project to use 2017 versions of the above mentioned dlls (We have VS2017). I am getting them from the below folder.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
After upgrading, when I build my solution, I get the following error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.NETFramework.targets(56,5): warning : Resolved file has a bad image, no metadata, or is otherwise inaccessible. The system cannot find the path specified. (Exception from HRESULT: 0x80070003)
I am not familiar with MSBuild so not sure how to proceed.
The error takes me to the following line in the MSBuild code:
GetDependsOnNETStandard Condition="'$(_RunGetDependsOnNETStandard)' == 'true'"
References="#(_CandidateNETStandardReferences)">
<Output TaskParameter="DependsOnNETStandard" PropertyName="DependsOnNETStandard" />
</GetDependsOnNETStandard>
There is an outstanding issue with Visual Studio 2017 and DependsOnNETStandard that should hopefully be resolved in 15.8
I just encountered the same problem today when upgrading a project that was originally created VS 2015 and upgraded to VS 2017.
It looks like the upgrade of the projects misses a few elements in the XML that it needs.
If you edit the csproj files of the effected projects and add
<DependsOnNETStandard>false</DependsOnNETStandard>
to the top PropertyGroup like so:
<PropertyGroup>
...
<DependsOnNETStandard>false</DependsOnNETStandard>
</PropertyGroup>
It should resolve the issue. It did for me.
Details of the issue and discussion around it can be found at:
https://github.com/dotnet/sdk/issues/1544
According to your error log info, seems you are trying to build locally through Visual Studio or MsBuild command not TFS build.
Suggest you to use the latest version of dlls, Microsoft.TeamFoundationServer.Client and also upgrade your Visual Studio 2017 to latest version. For The system cannot find the path specified. issue try to
Clean All Projects.
Unload All Projects
Reload All Projects.
ReBuild Solution
Another way is :
Close the solution
Delete bin folder
Delete all obj folders
Open solution and build
If all of above still not work, suggest you add a more detail log and sample code for troubleshooting.

Code builds fine in VS (2017) but not msbuild or TFS "assemblies manifest does not match the assembly reference

OK - here we go again. I posted an almost identical question here, but this one is a little different. I just generated a new version of a NuGet package and updated all of our csproj and config files to point to it and it builds locally fine, but when I kick off a TFS build it fails with the message:
##[error]ASPNETCOMPILER(0,0): Error ASPCONFIG: Could not load file or assembly 'PacsgearLib, Version=2.5.4.0, Culture=neutral,
PublicKeyToken=05b30ac9ab9dbb8e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Pacsgearlib 2.5.4 is the NuGet package I just generated, but all of our other projects build fine (and they share a lot of the same code). The main difference is that this project has a website in it. MSBuild is version 15.5.180.51428.
Here's a picture of the actual error:
Any ideas here? I've tried NuGet package manager to uninstall the package and reinstall it for the website and that hasn't helped.
I've been at this for a few hours so I thought maybe someone else (or a second set of eyes) might help.
I also just saw this and will check it out first thing Monday morning.
I finally got this to work by taking out the assemblybinding section of the web.config (someone else suggested that in another related post) and I also found a few .csproj files that had not been properly updated and were still pointing at 2.5.3.
If the local builds fine, and the error exist with TFS build. Besides, all of our other projects build fine (and they share a lot of the same code).
Combine with both, the issue may related to the specific package PacsgearLib, Version=2.5.4.0 on build agent. You could try to delete the packages and clean build agent, then try again.
Another way is update your package version number(do not update the package content), use TFS trigger the build again. Check if TFS build server will pick up the latest version of package.
Also set system.debug=true to Enable Verbose Debug Mode with more detail log info for troubleshooting

VS2017 Found Conflicts between different versions of "System.Runtime" that could not be resolved

I had a Visual Studio 2015 solution with 3 projects and then started using VS 2017 adding 2 new xunit projects. When I build everything succeeds but the tests are being discovered in Test Explorer.
I reviewed this question Found conflicts between different versions of the same dependent assembly that could not be resolved and set my Build output to Diagnostic and I am getting a warning saying:
1> C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2052,5): warning MSB3277: Found conflicts between different versions of "System.Runtime" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
i have updated the 3 .csproj files from
Project ToolsVersion="14.0"to
Project ToolsVersion="15.0"
added <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to the 2 VS2017 projects which did not have it
set Test -> Test Settings -> Default Processor Architecture to x64 and my Build -> Configuration Manager -> Platform to x64 or Any CPU (some projects do not allow x64?)
I have reinstall nuget packages across the solutions with Update-Package -reinstall
updated and repaired VS2017
I can see my tests on solution load but once I build the solution the tests are grayed out. Then I tried to run one and they say
4/4/2018 4:34:25 PM Warning] Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run:
DatabaseRestoreManager.exe, RestoreBaseLib.IntegrationTests.dll, RestoreBaseLib.Tests.dll, RestoreBaseLib.dll, Restores.exe are built for Framework Framework45 and Platform X64.
Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings.
[4/4/2018 4:34:26 PM Warning] [xUnit.net 00:00:00.1993869] Exception discovering tests from RestoreBaseLib.IntegrationTests: System.BadImageFormatException: Could not load file or assembly 'RestoreBaseLib.IntegrationTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'RestoreBaseLib.IntegrationTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
Most people with this issue seem to have the problem in a nuget package but my issue seem to be a msbuild or VS15 to VS17 upgrade with testing and System.Runtime.
Is there anything that can fix this? I want to be able to run xunit tests in VS17.

TransformXml could not be loaded

I have a old solution which worked fine with VS 2012 and now I migrate it to VS 2013.
When I try to build a configuration which involve web.config replacement i got this error:
Error 1 The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What it mean is that there no build tools in my v11.0 which is right. Because I use Visual Studio 2013. (the build tool are in a folder called v12.0) One option is to just copy my build tool to the right place but im searching for a real solution.
I found in my .csproj file these config:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
But im not really understand why it then v11.0 could be. I have tried multiple things to change these like set VisualStudioVersion explicit but it changed nothing.
So my question: where the heck come these path from and where can I configure it?
Since vs2012 MS tries to keep sln file untouched if there is no reason to upgrade it (to allow opening sln in the old VS).
If you’ve upgrade from vs2012 to vs2013 there can be chance you are opening solution in vs2012 (it happen to me in many updated solutions).
Try to check beginning of the sln file
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
or:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
If you wish to change it by VS, open sln in vs2013 and then select solution root node in solution explorer and the File > Save .sln (Ctrl+S)

TFS Build 2010 CodeActivity: Cannot Load Assembly in XAML

I am attempting to add a custom “activitycode” to a TFS Build. I wrote this months ago and had it working on a now defunct test environment. I am attempting to resurrect the use of the code onto a new test platform, and am running into issues.
When I open my build.xaml, I receive the dreaded red-box of pain where my custom activity should be, stating “Assembly could not be loaded because of an error in the XAML.” In the ErrorList, I also have found “Could not find type '.DeploySSRSReportActivity' in assembly 'ReportingServicesDeploy'.”
I have confirmed that my DLL is checked into source control and that the build controller is pointing to it.
Peeking into the raw XAML, I see that the build.xaml file defines the assembly as
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy
The line where my custom activity (and where V.S. finds the error) is:
<rsd:DeploySSRSReportActivity CurrentBuild="[BuildDetail]"
SourcesDirectory="[SourcesDirectory]"
mtbwt:BuildTrackingParticipant.Importance="High"
xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client"
xmlns:mtvco="clr- namespace:Microsoft.TeamFoundation.VersionControl.Common;assembly=Microsoft.TeamFoundation.VersionControl.Common"
xmlns:ras="clr-namespace:ReportingServicesDeploy;assembly=ReportingServicesDeploy"
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy"
xmlns:sad="http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation"
xmlns:sad1="clr-namespace:System.Activities.Debugger;assembly=System.Activities" />
The DLL is named ReportingServicesDeploy.dll. The namespace within the DLL is ReportingServicesDeploy, and the name of the activity class is DeploySSRSReportActivity.
Where is the linkage failing so that I am getting that error?
When your attempting to edit the xaml your doing this on your machine directly, tfs and sourcecontrol is not involved, the location on server for controller is where build agent will look for assemblies during the build and where VS will get them when opening build definition for config.
Your error possibly is coused by old version being used.
The assemblies must be available for visual studio on your machine - one option is to add them to GAC or to post in VS bin folders. Start new instance of studio afterwards
To intall into GAC run this from Visual Studio command line:
gacutil /i "Path\To\YourAssembly.dll"
To remove assembly run following from Visual Studio command line:
gacutil /u "YourAssembly"
For studio assemblies i believe this is the folder:
Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies