I'm trying to create a .netstandard nuget package following these instructions, using VS2017 RC. It builds fine, but when I try to create the package using
msbuild /t:pack /p:Configuration=Release
I get an error, that the target pack is not available in my solution:
error MSB4057: The target "pack" does not exist in the project.
I'm not really sure what to do with this message or where I should be looking to fix it. Any suggestions?
Thanks to an answer on the MSDN forums I was able to get it working.
You'll have to specify your .csproj in the build command so it won't try to use the solution file (.sln).
msbuild "C:\Users\Administrator\Documents\visual studio 2017\Projects\AppLogger\AppLogger\AppLogger.csproj" /t:pack /p:Configuration=Release
Additionally I had to install the NuGet.Build.Tasks.Pack" package from NuGet.
The command msbuild /t:pack /p:Configuration=Release is specifying that MSBuild should run the pack target within the build script. The error indicates that MSBuild isn't able to find that target within the build script (or one of it's imports). Have you double checked your prerequisites? You're either using the wrong build script or it's missing an <import> tag.
You must import targets before using them. In project file before using targets write:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Related
I know Since the release of msbuild 15 (vs 2017) that NuGet is now fully integrated into MSBuild.
I have a nuspec file with defining variables of package properties like:
<metadata>
<id>$id$</id>
<version>$version$</version>
<authors>$authors$</authors>
...
</metadata>
The nuspec file is located in the same folder of the project.
When using nuget tool to create the package , it works fine.
nuget pack
When using msbuild v15, it raise an exception.
run the command:
msbuild -version
Microsoft (R) Build Engine version 15.8.168+ga8fba1ebd7 for .NET Framework
15.8.168.64424
msbuild /t:pack /p:configuration=release /p:NuspecFile=mylib.nuspec
raise exception:
C:\Program Files\dotnet\sdk\2.1.402\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(199,5): error : Value cannot be null or an empty string.
The strange is that dotnet sdk version 2.1.402 raises the exception.
I tried msbuild installed with vs2017 with its path and also it raises the same exception.
When i substitute the variables with its values, msbuild is working fine.
The question
Is this a bug in msbuild version 15.8.168.64424 or i missed something ?
In other words, Can msbuild support using the metadata variables of the package?.
As has been mentioned in the comments, you no longer need a Nuspec file as most aspects can be controlled via properties in the csproj file or additional metadata on items (e.g. if you need additional content).
If you do need a nuspec file for some reason, you need to provide the variables for substitution yourself. You can do this in a target inside the csproj file like this:
<Target Name="SetNuspecProperties" BeforeTargets="GenerateNuspec">
<PropertyGroup>
<NuspecProperties>$(NuspecProperties);id=$(AssemblyName)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);config=$(Configuration)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);version=$(PackageVersion)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);description=$(Description)</NuspecProperties>
<NuspecProperties>$(NuspecProperties);authors=$(Authors)</NuspecProperties>
</PropertyGroup>
</Target>
I have a C# solution with VS 2017, containing an app project and a test project. I can use the "create app package" wizard to create one single bundle for x86 and x64. However, I would like to automate this process, which means I need to use msbuild in command line to do the same work.
With the reference from here and here, I got:
msbuild .\MyProject.sln /p:AppxBundle=Always /p:AppxBundlePlatforms="x86|x64" /p:Configuration=Debug
But I will get errors for my test projects, like:
MakeAppx : error : Error info: error 80080204: The package with file name "Tests.XXXX.Shared.Uwp_1.0.0.0_x86_Debug.appx" and package full name "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx_1.0.0.0_x86__xxxxxxxxxxx" is not valid in the bundle because it has a different package family name than other packages in the bundle. The expected package name is xxxx-Test.xxxxTestApp....
My guess is that I should not use "Always" for AppxBundle, but I cannot find any document online mentioning how to set this value as "If Needed". I also tried to add "Never" in project properties for the test project, but the command line argument seems to overwrite that.
So my question is: How to exclude a test project from the solution when creating a bundle using msbuild in the command line?
How to exclude a test project from the solution when creating a bundle using msbuild in the command line?
To resolve this issue, you can build the project file directly when you create a bundle using MSBuild in the command line:
msbuild .\YourProjectFile.csproj /p:AppxBundle=Always /p:AppxBundlePlatforms="x86|x64" /p:Configuration=Debug
Alternatively, you can open test project file and add the following properties at the end of the first <PropertyGroup> element to exclude the test project to be included:
<PropertyGroup>
<AppxBundle>Never</AppxBundle>
</PropertyGroup>
Check this thread and the document for some more details.
Hope this helps.
When I create a nuget package based on this document with Visual Studio 2017. I can create the nuget package from the Visual Studio, but I failed when I create the nuget with MSBuild command line:
msbuild /t:pack
The error info:
MSB4057: The target "pack" does not exist in the project.
I have search this thread and this thread, but none of them resolve my issue.
So I do not know how to fix this issue, Any suggestions?
error MSB4057: The target “pack” does not exist in the project when I create nuget package with MSBuild
It seems you are using the .sln solution path instead of the .csproj project path when you packing your package with MSBuild.
Since the package metadata is contained directly in the .csproj file, so you should switch the .sln solution path to the appropriate .csproj project path.
The command looks like:
msbuild "YourProjectPath\xxxx.csproj" /t:pack /p:Configuration=Release
Hope this helps.
I am having a problem with nuget (version 4.3.0.4406) and msbuild (version 15.3.409.57025). I am using VS2017 to create class library. Using the pack capability of VS2017 i can successfully create a nuget package (that i can install in another solution). Now i want to add an install.ps1 script to the package in the tools folder that runs when the nuget is installed.
In the csproj file i am specifying multiple target frameworks:
<TargetFrameworks>net45;net452</TargetFrameworks>
I cannot figure out how to do this. I've created a nuspec file using the nuget -spec command which generates a simple nuspec file. When i use the msbuild command with the /t:pack and /p:Nuspecfile=path.to.nuspec I get the following errors:
NuGet.Build.Tasks.Pack.targets(141,5): error : Value cannot be null or an empty string.
I have nuspec files from other projects (from VS2015 solutions) that work without problem, and the structure of the one i am using now is basically the same. Can anyone let me know whether i am trying something that cannot be done?
You can pack any item by updating its metadata in the csproj file:
<ItemGroup>
<None Update="install.ps1" CopyToOutputDirectory="PreserveNewest" Pack="true" PackagePath="\tools" />
</ItemGroup>
Note that the ps1 file is only run for projects using packages.config to reference the NuGet package and you should investigate alternative ways to accomplish what you are trying to do with the script as PackageReference is now more likely to be used instead.
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