Having an issue with a ResGen call during a build of a .NET 2.0 project from within Visual Studio .NET 2010, this thread suggests:
Add this to your MSBUILD command-line:
/p:ResGenExecuteAsTool=true;ResGenToolArchitecture=ManagedIL;ResGenTrackerSdkPath="%programfiles(x86)%\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\x64"
I've searched for hours without success trying to find a way to do this from within my Visual Studio .NET project.
Therefore my question is:
How can I change the MSBUILD command line of a .NET 2.0 (class library) project in Visual Studio 2010?
I have no fear changing my ".csproj" file, I would prefer not to change MSBuild files that were shipped with Visual Studio, if this is possible.
Update and solution:
Thanks to Oded's comment and answer, I added the following two lines:
<ResGenTrackerSdkPath>%programfiles(x86)%\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\x64</ResGenTrackerSdkPath>
<TrackFileAccess>false</TrackFileAccess>
right inside the very first <PropertyGroup> section of my ".csproj" file (i.e. after line 3). This made the file compile successfully!
I now check and see whether it also runs successfully.
Like all properties in MSBuild, what you can pass in through the command line can be added in the project file in XML elements instead.
For example:
<ResGenTrackerSdkPath>%programfiles(x86)%\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\x64</ResGenTrackerSdkPath>
And:
<ResGenExecuteAsTool>true</ResGenExecuteAsTool>
etc...
Related
Here the repro steps:
Start VS 2017
Create a cross-platform project ==> Sample.sln
Build it in VS ==> Ok
By building with it with the command "msbuild Sample.sln" I get 4 times the following error message: error MSB4066: The attribute "Version" in element "PackageReference" is unrecognized.
Anything missing in the .csproj files I am supposed to add?
Thanks in advance for your support.
Make sure that you use the path to msbuild.exe that is installed with Visual Studio. Use the Developer Command Prompt for Visual Studio 2017 if unsure, it has the PATH set up so that msbuild will point to the right executable.
This error happy when you use an old version of MSBuild (e.g. the version included in .NET Framework) that doesn't support the necessary features - metadata as attributes in this case.
I have a VS2017 solution with multiple projects that generates a cross-platform nuget-package. The package is generated by running nuget pack on my specific nuspec file. I would like to automatically performs this action during Visual Studio build instead of doing it manually each time. Is this possible?
Pack nuspec file during build in Visual Studio. Is this possible?
The answer is yes. You can simple add a pro-build or post-build event (Project->properties->Build Events) to generate nuget package with below command line:
nuget.exe pack "$(ThePathOfYour .nuspec)\TestPackNupsec.csproj.nuspec"
Note: You should add the nuget.exe as a system variable, so that you can use it anywhere without specifying the specific path of nuget, or you need specify the full path of nuget in that command line, like:
C:\Users\<UserName>\nuget.exe
With this command line in the build-event, we could generate Pack nuspec file during build in Visual Studio:
My sln is built in VS2017 and contains several .Net Standard class library dll. Build always works successfully in my local machine/virtual machine, with VS UI or just use devenv.com via command-line.
But, when I use TFS to create build task, error about InternalVisibleTo shows.
When I use MSBuild,
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" "C:\WorkArea\xxxxx\_work\1\s\xxxxx\Main\Source\xxxx.sln" /nologo /nr:false /t:"Clean" /dl:CentralLogger,"C:\WorkArea\xxxxx\tasks\MSBuild\1.0.55\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=30268741-631d-4ac8-b4d2-d5b2774b61e7|SolutionDir=C:\WorkArea\xxxxx\_work\1\s\xxxx\Main\Source"*ForwardingLogger,"C:\WorkArea\xxxxx\tasks\MSBuild\1.0.55\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:platform="Any CPU" /p:configuration="Debug" /p:_MSDeployUserAgent="TFS_6e1df8d0-1a29-425d-803c-d70779d0c76a_build_3175_345868"
it has the error:
When I use devenv.com,
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.com" "C:\WorkArea\xxxxxx\_work\1\s\xxxxx\Main\Source\xxxxxx.sln" /build "debug"
it has the error:
Is it a known issue or bug of Current Visual Studio 2017 (version 15.2 - 26430.6)? What's wrong with the AssemlyInfo? What's wrong with the TFS build?
You need to restore NuGet packages before attempting the build to resolve references to the reference assemblies that provide you the core types.
You can do this using msbuild /t:Restore (TFS/VSTS: use msbuild task) or nuget.exe restore (use a nuget.exe >= 4.0.0).
There must be some issue within the latest Visual Studio 2017. They, the Microsoft, change the project file structure of .Net Core / standard a lot from 2017 RC to current one.
I have a solution that contains a project with AutoGenerateBindingRedirects set to "true". When I build it via Visual Studio 2013, the .config file in the output directory contains an generated assembly binding redirect for EntityFramework, and the project runs. However, on the build server, which calls MSBuild, this property is not followed, which causes the project to fail to start. Does anyone have any idea on why there might be differences in the build results between the two methods?
For reference, the build server is executing a command like
MSBuild MySolution.sln /p:Configuration=Release,DefineConstants="SOMETHING" /t:Rebuild /tv:4.0
I get the same results when invoking this on my development machine, too, so it seems to be a peculiarity with MSBuild and/or Visual Studio. I've tried variations like
MSBuild MySolution.sln /p:Configuration=Release,DefineConstants="SOMETHING",AutoGenerateBindingRedirects=true /t:Rebuild /tv:4.0
to no avail.
I've recently upgraded to Visual Studio 2013, which has caused back to back problems when building externally using MSBuild (API or Executable with command line args)
Issue #1
When building with MSBuild it doesn't generate Fake assemblies which are required for our Unit Tests, this leads to build failures. A simple build in visual studio fixes this temporarily, until a new fake assembly needs to be generated.
Issue #2
When running code analysis this complains with the following:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(284,5):
error MSB4127: The "CodeAnalysis" task could not be instantiated from the assembly "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\.\FxCopTask.dll".
Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.CodeAnalysis' to type 'Microsoft.Build.Framework.ITask'.
I only have Visual Studio 2013 installed on my machine, apparently installing an older version could fix the issue, but it's not something which I can do. (VS 2013 Ships with its own MSBuild 12.0 which is located in a different directory to the previous MSBuild).
I'm unsure why Visual Studio is behaving any differently to MSBuild, i'm simply pointing to the solution file like so...
msbuild.exe "path\solution.sln" /property:Configuration=Debug
So, Visual Studio 2013 comes with a new version of MSBuild i.e. MSBuild 12.0. Once installed, it changes the path so that the new version is used by default.
Looks like your solution compiles with visual studio 2012, you can either specify the full path to msbuild.exe such as
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild "path\solution.sln" /property:Configuration=Debug
or set the visual studio 2012 environment variables by running the following before executing msbuild
"%VS110COMNTOOLS%"\vsvars32.bat // VS2012 environment variables
EDIT: Using MSbuild 12.0 assemblies "C:\Program Files (x86)\MSBuild\12.0\Bin\" fixes the issue with the code Analysis bug.