I am currently packaging a nuget package for my code generator project and I have gotten so far as to include an executable into the tools directory and a build target into the process.
Partial from the nuspec
<files>
<file src="cgbr.targets" target="build\cgbr.targets" />
<file src="cgbr.json" target="content\cgbr.json" />
<file src="..\bin\CGbR.Lib.dll" target="lib\CGbR.Lib.dll" />
<file src="..\bin\cgbr.exe" target="tools\cgbr.exe" />
</files>
Content of the cgbr.targets file
<?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BeforeBuild">
<Exec Command="cgbr.exe $(ProjectDir)"/>
</Target>
</Project>
Now when I install the package I see that it is included into the build process. Unfortunately the path to cgbr.exe is invalid and I am a little stuck. Of course I could use $(SolutionDir)packages\CGbR.0.3\tools\cgbr.exe but than I would have to modify it every time I change the version.
To clarify: I need the path to my packages tools path.
Edit: Found a related post
You probably want a relative path to the tool from the targets file. There are a number of predefined properties in msbuild. Perhaps the most useful for these scenarios is MSBuildThisFileDirectory which returns the full path to the directory of the current proj file. An example:
<Exec Command=""$(MSBuildThisFileDirectory)..\tools\cgbr.exe" "$(ProjectDir)""/>
Related
What I've tried so far:
I've got the following .nuspec file, defining my package (simplified for better readability):
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
<metadata>
.
.
.
<dependencies/>
<contentFiles>
<files include="any\any\config\*.*" buildAction="None" copyToOutput="true" flatten="false"/>
</contentFiles>
</metadata>
<files>
<file src="bin\Assembly.dll" target="lib\net461" />
<file src="bin\Assembly.pdb" target="lib\net461" />
<file src="Config\cf.xml" target="contentFiles\any\any\config"/>
<file src="Config\cf.txt" target="contentFiles\any\any\config"/>
</files>
</package>
As you can see, it contains a compiled Assembly along with it's debug symbols file as well as two content Files in a sub directory.
This results in the following compilation output, where the Assembly.dll is extracted to the output directory as well as the config sub directory (with the two cf.* files in it):
Question:
What I want to do is to move the sub directory config one step up in the directory tree, so it sits next to the output directory - basically maintaining the structure of the file input in the .nuspec file (assuming bin is the output directory of my .csproj):
How can I tell the NuGet package the exact location where I want the contentFiles to be extracted to?
You can achieve this by creating a MSBuild target that moves your config folder one level above the project build output.
Add a .targets file with the following content to your NuGet's build\net461 folder:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Sets up items for target MoveConfigFiles, so that they can be used as Inputs and Outputs. -->
<Target Name="PrepareMoveConfigFiles" AfterTargets="Build">
<!-- ItemGroup wrapped in Target to delay evaluation of contained Items -->
<ItemGroup>
<!-- Contains source locations of files to be moved -->
<ConfigSourceFiles Include="$(OutputPath)\config\**\*.*" />
<!-- Contains target locations of files to be moved -->
<ConfigTargetFiles Include="#(ConfigSourceFiles->'%(FullPath)'->Replace('\config\', '\..\config\'))" />
</ItemGroup>
</Target>
<!-- Moves files from $(OutputPath)\config to $(OutputPath)\..\config,
then deletes $(OutputPath)\config. -->
<Target Name="MoveConfigFiles" AfterTargets="PrepareMoveConfigAndSqlFiles" Inputs="#(ConfigSourceFiles)" Outputs="#(ConfigTargetFiles)">
<Move SourceFiles="#(ConfigSourceFiles)" DestinationFiles="#(ConfigTargetFiles)" />
<RemoveDir Directories="$(OutputPath)\config" />
</Target>
</Project>
The target PrepareMoveConfigFiles is executed after the Build target (which guarantees the NuGet's contents exist in build output), and sets up items used as Inputs and Outputs of the next MoveConfigFiles target. (The items are set inside this target to ensure they are evaluated after the Build target has completed. If the item definitions would be placed below the Project level, they would be evaluated earlier and thus would potentially be empty because the files of the content folder have not yet been deployed.)
The ConfigSourceFiles item just contains the source files, and ConfigTargetFiles takes the paths of all ConfigSourceFiles and replaces \config\ with \..\config\, which leads to the desired target locations.
The MoveConfigFiles target then uses the Move and RemoveDir tasks to accomplish the movement of files and deletion of the original config folder.
It is a weird question...
You have several things to do a nuspec file;
The main are "the nuget packages".
Your nuspec line:
<file src="bin\Assembly.dll" target="lib\net461" />
<file src="bin\Assembly.pdb" target="lib\net461" />
I don't understand Assembly.pdb to distribute it, but is not important.
The goal of this lines are distribute yout dlls in your projects.
When you compile your solution (in your solution dir) it search for this dlls in same root application directory or else check if are register on system (gac mainly).
On the other hand other kind of lines are the "content" into nuget
<file src="Config\cf.xml" target="contentFiles\any\any\config"/>
<file src="Config\cf.txt" target="contentFiles\any\any\config"/>
This is additional content but maybe it may not will be used in the project.
If you want a route system you can use content, but you could have problems using the dlls.
So, I suppose that maybe you would this:
<file src="bin\Assembly.dll" target="contentFiles\any\any\bin" />
<file src="bin\Assembly.pdb" target="contentFiles\any\any\bin" />
<file src="Config\cf.xml" target="contentFiles\any\any\config"/>
<file src="Config\cf.txt" target="contentFiles\any\any\config"/>
And other nuspec example (I would not do this, but, it is possible to do it):
<files>
<file src="content\bin\youtBinayFile" target="content\bin\youtBinayFile" />
<file src="content\Config\YourConfigFile" target="content\Config\YourConfigFile" />
<file src="readme.txt" target="readme.txt" />
</files>
I hope I've helped
How do I compile with mc.exe in the correct way. Currently I have a build step which runs the relevant command but looking at developer network
There seems to be a better way.
I am not a expert with msbuild so please excuse how easy this question is. Googling has revealed no help
<Project
DefaultTargets="Build"
ToolsVersion="14.0"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Filter Include="Message Source Files">
<Extensions>mc;</Extensions>
<UniqueIdentifier>{B796B525-44D3-4260-8C76-705DBADA1043}</UniqueIdentifier>
</Filter>
</ItemGroup>
<ItemGroup>
<MessageCompile Include="a.mc">
<GenerateBaselineResource>true</GenerateBaselineResource>
</MessageCompile>
</ItemGroup>
<Target Name="Build">
<DontKnowWhatGoesHere Sources="#(MessageCompile)"/>
</Target>
</Project>
MSBuild build are usually extended via .targets files, that have to be included in the project, and they extend the existing build proces. The WDK tasks for MSBuild page confirms this:
These command-line tools need to be exposed to MSBuild as tasks (contained in targets) so that they can be run during the build process.
The WDK MSDN page also has a help page on Windows driver targets:
The WindowsDriver.Common.targets, WindowsDriver.masm.targets, and WindowsDriver.arm.targets files provide the targets that are necessary to build a driver.
A quick grep in my C:\Program Files (x86)\Windows Kits\10\build directory showed that the MessageCompile target (the step that actually processes the MessageCompile items) is defined in the build\WindowsDriver.Common.targets file.
After importing the targets in your project you can do one of the following:
<Import
Project="C:\Program Files (x86)\Windows Kits\10\build\build\WindowsDriver.Common.targets" />
<!-- Option A: -->
<Target Name="Build" DependsOnTargets="MessageCompile">
<!-- no need to do anything, the dependency target should do the work -->
</Target>
<!-- Option B: -->
<Target Name="Build" DependsOnTargets="MessageCompile">
<!-- Use the Mc task which is the actual wrapper around the .exe,
see the .common.targets file for the list of all parameters -->
<Mc
Sources ="#(MessageCompile)"
ToolExe ="$(MessageCompileToolExe)"
ToolPath ="$(MessageCompileToolPath)"
Generated
/>
</Target>
I am trying to create a Nuget package for a library that depends on ghostscript and therefore references gsdll32.dll - an unmanaged library. I can't just included that a standard dll reference. Where do I put this in the nuget directory structure?
Add a build folder to the package and, if the package for example has the id MyPackage, add a MSBuild target file called MyPackage.targets to this folder. It is important that the .targets file has the same name as the .nuspec file. In the .nuspec file you must have a section like this:
<files>
<file src="lib\*.*" target="lib" />
<file src="build\MyPackage.targets" target="build" />
</files>
This will add an MSBuild element in the project file pointing to the .targets file.
Furthermore, to only register the managed dlls, add a section like this:
<references>
<reference file="MyManaged.dll" />
</references>
The .targets file should look something like this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="CopyMyPackageFiles" AfterTargets="AfterBuild">
<ItemGroup>
<MyPackageFiles Include="$(MSBuildThisFileDirectory)..\lib\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(MyPackageFiles)" DestinationFolder="$(OutputPath)" >
</Copy>
</Target>
</Project>
Now, all files - including unmanaged files - will be copied to the project output folder (e.g. \bin\debug) after the build.
The above reference can work, but it actually modifies your post build event to push files over, which may not actually fix your issue if you have the situation we did.
The issue we were having was a dependent DLL could not be registered, but had to exist side by side with another DLL which needed to be registered by nuget so it needed to exist in the lib directory but not be registered.
The nuspec reference now allows you to specify which DLLs in the lib directory get explicitly registered in the visual studio project now, you simply need to add into your nuspec file in the metadata area an explicit references list (if this does not exist the default behavior of nuget is to attempt to register everything under lib).
Here is an example nuspec file of what I mean:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>SomePackageID</id>
<version>1.0.1</version>
<title>Some Package Title</title>
<authors>Some Authors</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Blah blah blah.</description>
<references>
<reference file="ceTe.DynamicPDF.Rasterizer.20.x86.dll" />
</references>
</metadata>
<files>
<file src="\\SomeNetworkLocation\ceTe.DynamicPDF.Rasterizer.20.x86.dll" target="lib\ceTe.DynamicPDF.Rasterizer.20.x86.dll" />
<file src="\\SomeNetworkLocation\DPDFRast.x86.dll" target="lib\DPDFRast.x86.dll" />
</files>
</package>
As you can see, ceTe.DynamicPDF.Rasterizer.20.x86.dll needs to be registered, but DPDFRast.x86.dll simply needs to exist in that directory to support the other DLL and won't be registered but through some dynamic referencing magic will ultimately be copied over into the destination bin directory anyway because visual studio sees that the first DLL is dependent upon the second.
Here is the original nuspec reference.
Response on the Nuget forum: http://nuget.codeplex.com/discussions/352689
pranavkm:
The SQLCE package has a similar issue that we handle via PS
scripts. Checkout out the scripts at
https://bitbucket.org/davidebbo/nugetpackages/src/1cba18b864f7/SqlServerCompact/Tools.
I largely got this to work using Lars Michael's method, but one thing I needed to add comes from James Eby's answer. Visual Studio was trying to register all the dll's in my lib directory, so I added a references element to the metadata in the nuspec file to tell it to only register the managed dll:
<references>
<reference file="FANNCSharp.dll" />
</references>
Also in
<MyPackageFiles Include="$(MSBuildProjectDirectory)\..\Packages\MyPackage\lib\*.*"/>
I first tried the id of my package FANNCSharp-x64, but it needed the full package name: FANNCSharp-x64.0.1.4.
One problem I had was that the packages path wasn't always in the same place relative to the project file. The following worked for me:
Within the NuGet package, place your unmanaged DLLs in the lib\native folder.
Add the following script to the tools folder:
install.ps1
#This script creates or updates a PackagesPath property in the project file
param($installPath, $toolsPath, $package, $project)
$project.Save()
#Load the csproj file into an xml object
[xml] $xml = Get-Content -path $project.FullName
#grab the namespace from the project element
$nsmgr = New-Object System.Xml.XmlNamespaceManager -ArgumentList $xml.NameTable
$nsmgr.AddNamespace('a',$xml.Project.GetAttribute("xmlns"))
#find or create the property
$property = $xml.Project.SelectSingleNode("//a:PropertyGroup//a:PackagesPath", $nsmgr)
if (!$property)
{
$property = $xml.CreateElement("PackagesPath", $xml.Project.GetAttribute("xmlns"))
$propertyGroup = $xml.CreateElement("PropertyGroup", $xml.Project.GetAttribute("xmlns"))
$propertyGroup.AppendChild($property)
$xml.Project.InsertBefore($propertyGroup, $xml.Project.ItemGroup[0])
}
#find the relative path to the packages folder
$absolutePackagesPath = (get-item $installPath).parent.FullName
push-location (split-path $project.FullName)
$relativePackagesPath = Resolve-Path -Relative $absolutePackagesPath
pop-location
#set the property value
$property.InnerText = $relativePackagesPath
#save the changes.
$xml.Save($project.FullName)
Add a targets file to the build folder. (Change "MyPackage" to the name of your package). Using a unique name for the target, like "CopyMyPackage", avoids conflicts with other packages trying to define the "AfterBuild" target. This targets file makes use of the $(PackagesPath) property defined by the above script.
MyPackage.targets
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="CopyMyPackage" AfterTargets="AfterBuild">
<ItemGroup>
<MyPackageSourceFiles Include="$(PackagesPath)\MyPackage.*\lib\native\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(MyPackageSourceFiles)" DestinationFolder="$(OutputPath)" >
</Copy>
</Target>
</Project>
Finally, add a "MyPackageReadMe.txt" to the Content folder. This will enable the package to install.
See also: http://alski.net/post/2013/05/23/Using-NuGet-25-to-deliver-unmanaged-dlls.aspx
For .NET Core this is pretty straightforward if you know what runtime platform your native code targets. You might notice a folder called "runtimes" in the .NET Core build folder under the bin tree when you build. It looks something like this:
These folders are designed to hold any platform specific stuff, including unmanaged/native DLLs.
In your NuGet package add a the following under the "Files" section:
<file src="[source path for file in package]" target="runtimes\[platform]\native\[file name]" />
When executing the application, the runtime environment will look for unmanaged dlls in the corresponding platform directory.
If you want to target multiple platforms, just add another file entry for each platform.
I have created a custom .targets file as below (Just added all the common tasks required in myproj.vcxproj file to .targets file)
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- *******************************************************************************************
Common tasks
******************************************************************************************* -->
<Target Name="H1">
<Exec Command="del /F/Q #(S_PACK_H1)" />
<RemoveDir Directories="#(D_PACK_H1)" />
</Target>
<Target Name="H2">
<Exec Command="del /F/Q #(S_PACK_H2)" />
<RemoveDir Directories="#(D_PACK_H2)" />
</Target>
<Target Name="H11">
<Exec Command="del /F/Q #(S_PACK_H11)" />
<RemoveDir Directories="#(D_PACK_H11)" />
</Target>
</Project>
All the macros/arrays like S_PACK_H1, D_PACK_H11 are defined in myproj.vcxproj file after which I am importing this in myproj.vcxproj file as below
<Import Project="C:\Program Files\MSBuild\MyCompany\Mycustom.targets" />
when I use the below cmd
msbuild myproj.vcxproj /t:H11
it gives an error "error MSB4057: The target "H11" does not exist in the project"
but If I have the same list of tasks in .vcxproj file instead of .targets file then it works fine.
Can I define macros in .vcxproj file and use them in .targets file? Will MSBuild be able to get that definition/value? If not then how do I go about using/passing something defined in vxcproj file in .targets file?
Why is msbuild not able to see my task when it is in .targets file Vs .proj file? what else do I need to do?
There is no obvious reason for this not to work. Yes you can define targets in an imported file and they should be available, regardless of where the import occurs. If you are using MSBuild 4.0 (there is no ToolsVersion attribute on your .targets file above, so I'm not sure) then you can generate a fully preprocessed file, like this:
> msbuild mproj.vcxproj /pp
Look for the preprocessed file in the same folder. Open it up in a text editor and search for your imported content, it should all be there. If not, perhaps the preprocessed file can shed some light into what is going wrong.
I want to include some dynamic part in the filename of the msi file my wix projects produce. This dynamic part should be controlled by variables which are part of my wix project and are declared like this:
<?define ProductVersion="7.1.0.1" ?>
Does anybody know about a way of sending that value of that wix variable to the linker to use it as a part of the output filename?
By the way: I'm using Wix3
You could update the OutputName of your .wixproj and use an MSBuild variable to pass through the version number or any other variable you like.
My build script looks like this:
set PRODUCTVERSION=7.1.0.1
MSBuild.exe /p:Configuration=Debug /p:ProductVersion=%PRODUCTVERSION% Installer.wixproj
And my WiX project looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>1.0.0.0</ProductVersion>
<ProjectGuid>{b7415c44-8d59-4ac2-b698-03e399a305e3}</ProjectGuid>
<SchemaVersion>2.0</SchemaVersion>
<OutputName>Installer.$(ProductVersion)</OutputName>
...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug</DefineConstants>
<WixVariables>ProductVersion=$(ProductVersion)</WixVariables>
</PropertyGroup>
...
</Project>
The output would be:
Installer.7.1.0.1.msi
The msi file name is not determined by your wix files, but by the light.exe -out switch. You can use the same value for -out and inside your wix files if you do the following in your build script, assuming it is a batch script:
set an environment variable with set
productversion=1.2.3
Pass -out foo%productversion%.msi to the
light.exe linker
use the same environment variable in
your wix files as
$(env.productversion)
Open *.wixproj (example: Setup.wixproj)
Go to the end of the file.
$(Configuration) = Debug| Release …
Set path of your application on AssemblyFiles.
<Target Name="BeforeBuild">
<GetAssemblyIdentity AssemblyFiles="..\App\bin\$(Configuration)\App.exe">
<Output TaskParameter="Assemblies" ItemName="AsmInfo" />
</GetAssemblyIdentity>
<CreateProperty Value="$(SolutionName)_%(AsmInfo.Version)_$(Configuration)">
<Output TaskParameter="Value" PropertyName="TargetName" />
</CreateProperty>
</Target>
Output = App_1.0.0.0_Debug.msi
I found a couple of great reference posts to do just this operation:
http://blog.tentaclesoftware.com/archive/2009/05/03/38.aspx
and a follow-on with a better method of creating the output file using a pre-build event:
http://blog.tentaclesoftware.com/archive/2010/08/05/99.aspx
I know the links are old, but the method is sound.
Here are the basic steps:
Put the version you wish to use into a file you can access from your project. I use the main executable of my installation because I also bind to that version in my wxs. In my case, since I am building with C# and use SVN, I have a template version of my assembly.cs, assembly.cs.txt, that I run subwcrev on as a pre-build event to create the assembly.cs that gets compiled into my executable (I actually do it in a separate project in my solution). Subwcrev inserts some date and revision information that I use to create a version in the form "major.minor.version.0" where I use "year.month.revision.0" for my version.
Now, I usually just set AssemblyFileVersion with this method, but to be able to use my version number in the wixproj build event referenced in the post above, I also need to set AssemblyVersion since that is what can be accessed with GetAssemblyIdentity. This method would be questionable if I were really using an assembly someone else links to, but for me it is OK since it is in my final application executable.
Follow the steps outlined in the second post (the first post discusses using the binding method for version in wxs and how to unload and edit the wixproj - valuable context for the second post).
Works like a charm!
Update some years later - it looks like the links I referenced are dead. Here is a snapshot of what I changed to make it work.
In my main product wxs file, I changed (some names have been changed or omitted to protect the innocent and the guilty):
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent" Guid="DF1AB3A6-17D0-4176-B3AC-C073AC47AA80">
<RemoveFile Id="PurgeAppFolder" Name="*.*" On="uninstall" />
<File Source="$(var.MyApp.TargetPath)" KeyPath="yes"/>
<File Source="$(var.MyApp.ProjectDir)\bin\Release\MyData.dll"/>
<File Source="$(var.MyApp.ProjectDir)\bin\$(var.MyApp.Configuration)\ICSharpCode.SharpZipLib.dll"/>
</Component>
</ComponentGroup>
to
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent" Guid="DF1AB3A6-17D0-4176-B3AC-C073AC47AA80">
<RemoveFile Id="PurgeAppFolder" Name="*.*" On="uninstall" />
<File Id="MAINEXECUTABLE" Source="$(var.MyApp.TargetPath)" KeyPath="yes">
<Shortcut Directory="ApplicationProgramsFolder" Id="MYAPPEXEAPF" Name="My App Name" Icon="MyAppIcon.exe" IconIndex="0" Advertise="yes" />
<Shortcut Directory="ApplicationDesktopFolder" Id="MYAPPEXEADF" Name="My App Name" Icon="MyAppIcon.exe" IconIndex="0" Advertise="yes" />
</File>
<File Source="$(var.MyApp.ProjectDir)\bin\Release\MyData.dll"/>
<File Source="$(var.MyApp.ProjectDir)\bin\$(var.MyApp.Configuration)\ICSharpCode.SharpZipLib.dll"/>
</Component>
</ComponentGroup>
and up at the top I added:
<Product Id="C86505BF-303F-4D6B-8F5F-43A57635F85D" Name="My Application Name" Language="1033" Version="!(bind.FileVersion.MAINEXECUTABLE)" Manufacturer="My Software Shop" UpgradeCode="D1C628E5-5478-4DA5-A31A-F9191D5B1544">
Note that the Version is bound to the file version of MAINEXECUTABLE, which is defined in the main product component.
I hope this helps!
If you have several configurations then inside .wixprj file you can do the following
<OutputName Condition="'$(Configuration)' == 'User'">User.Setup</OutputName>
<OutputName Condition="'$(Configuration)' == 'Designer'">Designerr.Setup</OutputName>
Since it's just a file name, why not have a post-build action that renames the file in your build script (assuming MSBuild)?
Do the variables have to be defined in WiX? I'm building my setup binaries from MSBuild, and I've simply set the output file name to MyProject_$(Platform) -- I expect that any MSBuild variable substitution will work equally well.
Product Id="GUID" Name="whatevername $(var.ProductVersion)"