This sample shows a .NET Core project which can be packaged into a nuget package just using dotnet pack, and when restored in another project, it integrates in the msbuild pipeline. One of the great things about this sample is it creates a nuget package that integrates with msbuild on linux, mac and Windows. However, the custom build code doesn't have dependencies on any other assemblies.
How can I adapt this sample to use code that uses a dependency?
Here are my failed attempts:
Attempt 1
I added a package reference to Newtonsoft.Json and changed the code to do some JSON serialisation. However, in the project that uses the build nuget, when I do a dotnet publish, I get the following error:
error MSB4018: The "Zip" task failed unexpectedly. [C:\git\MSBuild-Features-With-Nate-McMaster\Video-2\1-NuGet\Web.csproj]
error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified. [C:\git\MSBuild-Features-With-Nate-McMaster\Video-2\1-NuGet\Web.csproj]
Additionally, if my project didn't already have a dependency on JSON.NET, adding the build nuget would unnecessarily add it.
Attempt 2
I used nuget.exe spec to create a .nuspec file. At the end of the file, I added:
<files>
<file src="bin\Release\**" target="build" />
<file src="build\**" target="build" />
</files>
However, both "dotnet pack" and "msbuild /t:pack" ignore the file, and nuget.exe pack fails with the error Unable to find 'bin\Release\0-WriteATask\bin\Release\'. Make sure the project has been built..
If I try nuget.exe pack Zipper.nuspec or msbuild /t:pack /p:NuspecFiles=Zipper.nuspec, they both fail with the message Value cannot be null or an empty string..
Attempt 3
I edited the nuspec to remove all of the placeholders that are normally calculated from the project (any string starting and ending with a $). Then, doing a nuget.exe pack Zipper.nuspec created a nupkg file, and the net46 folder contains Newtsonsoft.Json.dll, but the netstandard1.3 folder does not.
The way MSBuild loads a task assembly can make it tricky to load additional assemblies that you may depend on.
Typically, the easiest way to solve this is to ship a copy of your dependencies inside your NuGet package. But your dependencies alongside your task assembly file in the package. There may be some additional complications that require you to use AssemblyLoadContext or the AppDomain.AssemblyResolve event.
You can do this without a nuspec file by forcing MSBuild to copy your assemblies into the local build output, and then copying them into your package. Set CopyLocalLockFileAssemblies=true, and add the items to _PackageFiles
Here's an example of how to do that: https://github.com/madskristensen/BundlerMinifier/blob/3333b5c38289a247391966443370ee6f4a29bf26/src/BundlerMinifier/BundlerMinifier.csproj#L35-L47
Hopefully, this will be addressed in the future, https://github.com/Microsoft/msbuild/issues/1312, and the task assembly resolution will use the NuGet cache.
Try it with the 9.0.1 version of Newtonsoft.Json, it worked for me, all these dll load problems went away, and it still targets .NET Standard. Although I did copy all the dependencies next to the task dll, but with the 10.x version even that didn't help.
I have created MSBuild script for build automation, earlier we were doing build manually on each server.
In my build script, it has the following target
Download Source Code
Build Solution
Now in the normal workflow at the very first time, it does download source code and builds all assembly files into bin/debug folder, during this process it does change assembly version number as well which is correct because since it does not have any previous timestamp information.
Till this step everything works fine, now what I am looking is that after download source code from SVN, I will stop my build process and copy my all assembly files from the server and paste into my source code folder under bin/debug and resume my MSBuild script execution for the second target. i.e. Build Solution
Since both source code and assembly files are same no code change, how can I handle such scenario in MSBuild that not to rebuild assembly files?
I have searched on google that how MSBuild check if all assembly files are up to date? and implement following way to handle it and it works as expected. Is there any better way to handle this scenario?
<Target Name="BuildSolution" Inputs="#(CsFiles)" Outputs="#(AssemblyFile)">
<MSBuild Projects="#(SolutionFile)" />
Our continuous delivery set-up, until recently, was delivering Service Fabric packages using the following command:
msbuild SFApp.sfproj /t:Package
This was necessary because the target Package is unavailable at the solution level. I.e. The command
msbuild SFSolution.sln /t:Package
Fails, as the target does not exist.
As our dependency mesh grows, it gets to a point in which most interfaces projects will not build without a solution file (to work around the "OutputPath does not exist" red herring). There seems to be a way to do that according to this answer. Unfortunately, while targets like Clean work…
msbuild SFSolution.sln /t:SFApplication:Clean
(…snip…)
Build succeeded.
0 Warning(s)
0 Error(s)
…the target Package won't!
msbuild SFSolution.sln /t:SFApplication:Package
(…snip…)
Build FAILED.
"SFSolution.sln" (SFApplication:Package target) (1) -> SFSolution.sln.metaproj :
error MSB4057: The target "SFApplication:Package" does not exist in the
project. [SFSolution.sln]
0 Warning(s)
1 Error(s)
(Solution/project folders/names omitted/paraphrased for clarity. I can provide the actual logs if necessary.)
So the question is: how could I, using the Command Line, build one project using the Package target and the solution file?
Or how can I otherwise package a Service Fabric application from the command line?
It's bad idea to compile sfproj file(and any other project file) without sln, because it can bring wrong content to its output from referenced projects. Only solution has a knowledge about what project to compile in what configuration.
To make Package similar to "Right Click->Package" in VS:
Just add to your sfproj the following target
<Target Name="ForcePackageTarget" AfterTargets="Build" Condition="'$(ForcePackageTarget)' =='true'">
<CallTarget Targets="Package"/>
</Target>
And then running normal build on solution you may trigger the package step by /p:ForcePackageTarget=true :
msbuild yoursolution.sln /t:Build /p:ForcePackageTarget=true /p:Configuration=Release /p:Platform=x64
Actually it performs two-in-one steps, build and package, with respect to Solution Configurations on all referenced projects
MSBuild only supports a small set of target names that can be specified at the solution level. As you've discovered, Package is not one of them. You'll need to execute two separate calls to MSBuild: one which builds the solution and one which calls the Package target on the sfproj. The Package target of an sfproj has a dependency on the Build target so it will ensure that the sfproj and its project dependencies are built.
I had the same problem and fixed it by changing the Platform in the failing projects to explicitly build for x64.
Click Build > Configuration Manager and make sure that the assemblies are compiled for the x64 platform, that should also set the Output Paths in the corresponding .csproj files.
The actual command line action that is being executed is this:
"C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe" "C:\agent\_work\1\s\Project\SFProject.sfproj" /t:Package /p:platform="x64" /p:configuration="release" /p:VisualStudioVersion="14.0"
Use the below script.
C:\Program Files (x86)\Microsoft Visual Studio 14.0> msbuild "Fabric.sfproj" /t:Package /p:Configuration=Release
Service fabric requires Target to be set in x64 platform,
So change all you reference projects target to x64 platform.
you can do this by using configuration properties of your solution. If x64 is not listed in 'Configuration Properties' click configuration manager in the same window and under platform column for the required project add new project platform as x64.
Hope this works for you.
We have had the exact same problem as you had and I have been looking around for a solution all over the web and did some experiments. Those are the steps that worked for us:
Don't manually add a target anywhere as suggested by other answers on StackOverflow. Not necessary. Especially in a CI environment, you want to build the projects separately anyways.
Prepare the projects in the Solution: Change the target platform for all projects to x64
Build the application
msbuild.exe SFAplication.xproj /p:Configuration=Release /target:rebuild
Package the App
msbuild.exe SFAplication.sfproj /p:Configuration=Release /target:Package
I try to integrate StyleCop in a Visual Studio solution. Installing StyleCop on each machine of each developer is something I would prefer to avoid. The suggestion I've seen several times (example) is to include the binaries of StyleCop within the project, storing them in version control.
I did that. It works on my machine, but fails on a different machine where StyleCop is not installed. After uninstalling StyleCop on my machine, it doesn't work there either.
The error message is the following:
Severity Code Description Project File Line
Error The "StyleCopTask" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild..\StyleCop 4.7\StyleCop.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\StyleCop 4.7\StyleCop.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. Demo
This is what I included in every .csproj file:
<Import Project="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.targets" />
The directory C:\demo\externs\Microsoft.StyleCop contains:
The copy of all the files from C:\Program Files (x86)\StyleCop 4.7,
The copy of C:\Program Files (x86)\MSBuild\StyleCop\v4.7\StyleCop.Targets.
What's wrong?
It appears that StyleCop.Targets contains an absolute path:
<UsingTask
AssemblyFile="$(MSBuildExtensionsPath)\..\StyleCop 4.7\StyleCop.dll"
TaskName="StyleCopTask"/>
In order to be able to use StyleCop on machines where the application is not installed, change this path to something similar to:
<UsingTask
AssemblyFile="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.dll"
TaskName="StyleCopTask"/>
Building my Jenkins/MSBuild solution gives me this error
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(483,9): error :
The OutputPath property is not set for project '<projectname>.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Latest' Platform='AnyCPU'. You may be seeing this
message because you are trying to build a project without a solution file, and have
specified a non-default Configuration or Platform that doesn't exist for this project.
[C:\<path>\<projectname>.csproj]
Any ideas?
EDIT
I have this in my .csproj file
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Latest|AnyCPU'">
<OutputPath>bin\Latest\</OutputPath>
</PropertyGroup>
I have figured out how it works (without changing sln/csproj properties in VS2013/2015).
if you want to build .sln file:
/p:ConfigurationPlatforms=Release /p:Platform="Any CPU"
if you want to build .csproj file:
/p:Configuration=Release /p:Platform=AnyCPU
notice the "Any CPU" vs AnyCPU
check the code analysis, fxcop, test coverage(NCover) targets, as well as the MSBUILD should be located properly. In my case its:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
but it can be different as you can see microsoft has given 6 cmd options to build code base::AMD (with cross plt, x86 & x64 options) and Windows(cross, x86, x64) and that also when code development happened with default JIT (it can be PreJIT ngen.exe, econoJIT)
I think more than this troubleshooting can be handle using power shell + msbuild. May be helpful for someone ...
Open up your csproj in a text editor and see if you have a property group section, should look something like this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Latest|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Latest\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
Do you have a 'Latest' build configuration? If not add the above section to the csproj.
As mentioned by perlyking, rather than editing the csproj XML The following worked for me. Here are the steps I used.
Open the Project Properties.
Select the Build Tab.
Under the Output section, Check that an output path is set. (if not set one, save the project and it should work).
If it is set, click on the "Browse..." button of the output path.
When the folder selection dialog opens, Navigate up one level in the
file browser and then re-select the output folder and click
the "Select Folder" button.
Save the project properties and it should work.
To add to what #James said, I found that if I looked at the project Compile properties in VS2013, the Build Output Path was specified. But when I examined the .csproj file directly, the OutputPath element was missing for the relevant build configuration. So in VS I simply made and reversed a minor edit to the output path, saved it, and that kicked the value into the project file, and I was then able to build.
I was using MSBuild to build multiple .sln files, and had added a new step to build a .csproj file as well, when I encountered this error.
#Saurabh's answer highlighted the root of the problem. However, when fixing it, adding /p:Platform=AnyCPU to the MSBuild Arguments section didn't fix it. I actually needed to update the Platform value on the build step.
All other build steps were using the $(BuildPlatform) variable value (which happened to be "any cpu", with a space in it).
(Had I been building multiple .csproj files, I probably would have created a second variable for the AnyCPU platform.)
For me the answer was to fix all the projects in Build > Configuration Manager.
If you have some projects where the name or platform does not match the solution configuration, you should change it so they all match.
I was running into this issue while updating an older project with additional project configurations for per-environment config transforms.
It turns out that when the project configurations were added to the csproj file, they were inserted after an Import element which caused the issue.
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'ProjectName.Dev|AnyCPU'">
...
Moving the Import element after all the PropertyGroup definitions fixed the problem for me.
Relevant similar case: https://stackoverflow.com/a/31072208/2452820
I got this error only when I was publishing my web project. I had mistakenly selected the wrong build configuration when setting up the publish profile.
I had same issue. I have updated my windows platform by using command line. Currently i got updated to windows#5.0.0 version. Then you need to search for file name "SQLite3.UWP.vcxproj". Try to change "v141" to "v140". Currently I am using Visual Studio 2015 professional. If it's Visual Studio 2017, then there is no need to change version in SQLite3.UWP.vcxproj file.
In my case this error happened because the output folder included a dot to make it relative to the current directory. The problem was solved by removing the dot.
The offending Build output path was:
.\bin\Output
The problem was solved by changing it to
bin\Output
The build output path can be found in the Build tab of the project properties, and there is a different path for each combination of Configuration and Platform.
Just had the issue for some service fabric stuff in MSBuild.
First step was right clicking each affected project and pulling up their Properties, selecting the Build tab, then setting the platform target to x64.
Second step was to go into the configuration manager and set each project to also use x64 for Debug and Release.
This was for a VS2017 project.
I had the same problem on a few projects. After adding a new configuration to the projects, the PropertyGroup was added at the very end of the Project file.
Moving the PropertyGroup to right after all the other configurations PropertyGroup fixed the issue.
I hope this helps.
I had this witha slightly unusual SLN/CSPROJ file arrangement:
I had project files:
A.csproj, with configurations "Dev" and "Production"
B.csproj, with configurations "Dev" and "Production"
C.csproj, a "common" library used by both A and B with configurations "Dev" and "Production"
And I had SLN files:
AC.sln, with configuration "Production" - this is used by jenkins to build project A and the common library
BC.sln, with configuration "Production" - this is used by jenkins to build project B and the common library
ABC.sln, with configuration "Dev" - this is used by developers in VS to write new code without having to keep opening different solutions (this answer is a simplified view of a 55-project solution)
I'd made an edit to the common library and introduced a dependency on project A. AC.sln would still build in jenkins but BC.sln gave an error saying:
The OutputPath property is not set for project 'A.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Debug' Platform='AnyCPU'.
It was initially puzzling because we don't even have a Debug config anywhere in any project; find in files for Debug| turned up 0 hits
ABC.sln that the human developers use in VS would also build fine. Building BC.sln gave an error that A.dll wasn't found
When the circular irresolvable problem of C depending on A was removed, everything started working again
This error is misleading and can be caused by a different issue. Check the entire message:
The OutputPath property is not set for project 'myproject'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='myconfig' Platform='AnyCPU'. This error may also appear if some other project is trying to follow a project-to-project reference to this project, this project has been unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform.
My build configuration was missing this node in the csproj:
<PlatformTarget>AnyCPU</PlatformTarget>
Despite saying AnyCPU was the selected Platform in the dropdown, the actual xml was not there. Adding it fixed the mismatch between the project and the other project it was referencing.
The OutputPath property is not set for project error message will appear if a Platform environment variable exists (as seems to happen on HP laptops) and the target of MSBuild contains a reference to another Visual Studio project.
After renaming the Platform environment variable my build now works.
It seems the parameter /p:Platform="Any CPU" gets applied to the target solution but doesn't 'carryover' to referenced projects. In my instance, the error message indicated referenced projects were using the environment variable Platform=MCD.
I had two project configs, Debug and Release. When the Release build was used, it was throwing this error. The issue I found was that in the csproj file, the Debug config was near the top and the Release config was all the way at the bottom.
Manually moving the Release build just below the Debug build fixed it.
I'm assuming I did something incorrectly when setting up my build configurations because this doesn't feel like something I should have had to manually adjust.
Edit the properties of the project:
Make sure "Configuration Properties->General->Output Directory" is not blank. Note, it's not called OutputPath here. You can probably copy the value from Intermediate Directory.
I encountered the same problems when build TheXTech (https://github.com/Wohlstand/TheXTech/wiki/Building-on-Windows#building-in-visual-studio-201520172019-and-cmake) recently. And finally I found it is a cmake -A issue. The correct arch for 64 bit on windows is x64, not Win64.
For some more reference, see https://cmake.org/cmake/help/v3.16/generator/Visual%20Studio%2016%202019.html#platform-selection, https://cmake.org/pipermail/cmake/2019-April/069379.html.
Go to Solution properties and change the configuration to Any CPU or X64 or X86, and if build is checked uncheck that for what you are getting error for. By default, project build that for build configuration in solution and throw error as mentioned when building the project.