Can I include an MSI file inside a Chocolatey package? - package

Can I put an MSI file or ISO image into a Chocolatey package?
So when I choco install foo, it won't download the MSI from another URL, but take the file from inside the package?

Yes, this is definitely possible. This is actually exactly what the ChocolateyGUI package does. You can see its .nuspec file here:
https://github.com/chocolatey/ChocolateyGUI/blob/develop/nuspec/chocolatey/ChocolateyGUI.nuspec
<?xml version="1.0"?>
<package>
<metadata>
<id>chocolateygui</id>
<version>$version$</version>
<title>Chocolatey GUI</title>
<authors>Chocolatey</authors>
<owners>Chocolatey</owners>
<projectUrl>https://github.com/chocolatey/ChocolateyGUI</projectUrl>
<projectSourceUrl>https://github.com/chocolatey/ChocolateyGUI</projectSourceUrl>
<packageSourceUrl>https://github.com/chocolatey/ChocolateyGUI/tree/develop/nuspec/chocolatey</packageSourceUrl>
<iconUrl>https://raw.githubusercontent.com/chocolatey/choco/master/docs/logo/chocolateyicon.gif</iconUrl>
<licenseUrl>https://raw.githubusercontent.com/chocolatey/ChocolateyGUI/develop/LICENSE</licenseUrl>
<bugTrackerUrl>https://github.com/chocolatey/ChocolateyGUI/issues</bugTrackerUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>
Chocolatey GUI is a nice GUI on top of the Chocolatey command line tool.
## Features
* View all **installed** and **available** packages
* **Update** installed but outdated packages
* **Install** and **uninstall** packages
* See detailed **package information**
## Notes
This package will only work correctly on Windows 7 SP1 through Windows 10 (1708) or Windows Server 2008 R2 SP1 through Windows Server 2016, and requires .NET Framework 4.5.2 at minimum.
</description>
<summary>A GUI for Chocolatey</summary>
<releaseNotes>
All release notes for Chocolatey GUI can be found on the GitHub site - https://github.com/chocolatey/ChocolateyGUI/releases
</releaseNotes>
<tags>chocolateygui chocolatey admin foss</tags>
<dependencies>
<dependency id="Chocolatey" version="[0.10.3, 0.11)" />
</dependencies>
</metadata>
<files>
<file src="chocolateyInstall.ps1" target="tools"/>
<file src="chocolateyUninstall.ps1" target="tools"/>
<file src="..\..\BuildArtifacts\ChocolateyGUI.msi" target="tools"/>
<file src="..\..\LICENSE" target="tools\LICENSE"/>
<file src="VERIFICATION.txt" target="tools"/>
</files>
</package>
Then, as you pointed out, you would then use Install-ChocolateyInstallPackage to perform the installation, which would then use the local MSI within the package, rather than first downloading it. You can see the installation script for ChocolateyGUI here:
https://github.com/chocolatey/ChocolateyGUI/blob/develop/nuspec/chocolatey/chocolateyInstall.ps1
$ErrorActionPreference = 'Stop';
$toolsDir = "$(Split-Path -parent $MyInvocation.MyCommand.Definition)"
$fileLocation = Join-Path $toolsDir 'ChocolateyGUI.msi'
$packageArgs = #{
packageName = $env:ChocolateyPackageName
softwareName = 'Chocolatey GUI'
file = $fileLocation
fileType = 'msi'
silentArgs = "/qn /norestart /l*v `"$env:TEMP\$env:ChocolateyPackageName.$env:ChocolateyPackageVersion.log`""
validExitCodes= #(0,1641,3010)
}
Install-ChocolateyInstallPackage #packageArgs
Remove-Item -Force $packageArgs.file
You can do the exact same thing with an ISO image file, and there is a walkthrough on the established best practice for using that ISO file here:
How To Mount An Iso In Chocolatey Package
NOTE: If you are planning on pushing the package to Chocolatey.org, please bear in mind the size of the MSI/ISO file. If this is especially large, it is probably best not to include it within the nupkg, but rather use a download link.

Like Gary said, you can include arbitrary files in the package.
I'd emphasize that it's not a great idea. You have to download the package file itself (that's what happens when you choco install foo). Moving the MSI/ISO inside the package means you'll be downloading it with the package file and, depending on the size, slowing down feedback at the console.
Using the proper helpers and external URLs gives you a lot of great behaviors, least of which, is the download progress bar!
If file storage is a problem, there are many free options including: GitHub, Google Drive, DropBox, etc. If you're creating "internal" packages for your company, a network share can work with file:// URLs.

Related

MSB4062 error publishing .NET7 app with publish profile

This is pretty easy to replicate but also code here:
https://github.com/dominicshaw/dotnet-publish-error
create an empty wpf project using .NET7
create a publish profile for ClickOnce
publish via command line (not visual studio)
Publish profile is almost totally standard (view here)
Command line from project directory:
dotnet publish PublishError.csproj -p:PublishProfile=ClickOnceProfile
Subsequent error:
MSBuild version 17.4.0+18d5aef85 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100\Microsoft.Common.CurrentVersion.targets(4149,5): error MSB4062: The "Microsoft.Build.Tasks.RequiresFr
amework35SP1Assembly" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKey
Token=b03f5f7f11d50a3a. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, a
nd that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\shawd\source\repos\PublishError\Publi
shError\PublishError.csproj]
I have the latest SDKs installed and VS2022 up to date. This only happens via command line - I am able to publish from Visual Studio (I am setting up devops, so require command line).
This happens regardless of adding nuget package for Microsoft.Build.Tasks.Core. Note however nuget package v15.1.0.0 is not available - I have tried 15.1.548 and the latest instead.
Totally at a loss! Any ideas very welcome.
Thanks vm
During the tests with your project and files, I finally managed to publish it successfully with the command dotnet publish PublishError.csproj -p:PublishProfile=FolderProfile.
Here is the document for dotnet publish, as is referred,
The preceding example uses the FolderProfile.pubxml file that is found
in the <project_folder>/Properties/PublishProfiles folder. If you
specify a path and file extension when setting the PublishProfile
property, they are ignored. MSBuild by default looks in the
Properties/PublishProfiles folder and assumes the pubxml file
extension.
And I also succeeded with dotnet publish with your project.
==============================
update on 11/19
So I suppose that the issue is resulted from your definition for -p:PublishProfile=ClickOnceProfile,it will change the path where this command would search for the publish file
A partial answer as my workaround for anyone struggling with a similar problem:
I have found it impossible to do this with the dotnet cli but I can do it with MSBuild if I specifically target 17.4 (VS2022). By default, my Azure DevOps Server 2020 capability is the 2019 MSBuild (15.X), so I have to be explicit:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Current\Bin\MSBuild.exe" /restore /Verbosity:m /t:Publish /p:RuntimeIdentifier=win-x64 /p:configuration=Release /p:PublishProfile=ClickOnceProfile
This works - so in my pipeline I have created a batch file which runs this, then I copy the files to my ClickOnce location.
Not ideal, but a working pipeline.
Interesting side note - this dotnet cli command which should be idenitical (and indeed uses the correct 17.4 MSBuild) - does not work (with the same error):
dotnet msbuild -target:Publish -property:RuntimeIdentifiers=win-x64;Configuration=Release;PublishProfile=ClickOnceProfile

Changing version of cxf on Service Mix

I want to change the version of cxf on Service Mix 7.0.1 where cxf version is 3.1.9 . Because of using Brave tracing that is implemented in 3.1.12 version of cxf.
So Is there a way to change the version of the CXF on Service Mix.
I have deleted manually everything in the system/apache/cxf folder that has 3.1.9 version and add a file with 3.2.5 version. But it is still not working. When I write feature:list all of the cxf dependencies are with 3.1.9 version...
Deleting files from the system folder won't work. It does not scan the system folder for files, but rather uses it as a cache to go looking for specific versions. You don't need to add new versions to system either because it will download them from the central maven repo it they arn't in system.
If it starts up without a data folder, it will install features & versions listed in org.apache.karaf.features.cfg
One would expect to be able to delete the data folder, change the version in org.apache.karaf.features.cfg & start it up, but I tried that and Camel was broken. Unsure why.
I find it easier to deal with it using the management console.
Install the management console by dropping the following xml file into the deploy folder:
<features name="features-murray" xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.0.0 http://karaf.apache.org/xmlns/features/v1.2.0">
<repository>mvn:io.hawt/hawtio-karaf/1.5.7/xml/features</repository>
<feature name="murray" version="1" install="auto">
<feature>hawtio-offline</feature>
</feature>
</features>
Then point your browser at http://localhost:8181/hawtio and login with SMX/SMX.
From OSGI/Features add the your new feature version with the plus button:
mvn:org.apache.cxf.karaf/apache-cxf/3.1.12/xml/features
It may take some time to install, because it downloads it from the net. I found it bounced me out of the management console also, but after logging back in I could uninstall the old cxf 3.1.9. It again logged me out of the management console, but after logging back in I had Camel active and CXF on 3.1.12.
No testing though - goodness knows what else is broken.

Building SQL Server Database Project In Ubuntu

I'm building an ASP.NET Core 2.0 Web API application that is hosted in an Ubuntu environment. So far, I've had great success getting things building and running (for the .NET Core app) in Ubuntu.
For the database, I have a SqlProj included in my solution. The project includes typical things such as tables, SPs, and pre/post deployment scripts. I'm using the following command (on my Windows-based dev machine) to build and deploy this project:
msbuild .\MyProject.DB.sqlproj /t:Build /t:Publish /P:SqlPublishProfilePath="./PublishProfiles/MyProject.DB.publish.xml"
When I take this approach, everything builds and deploys properly; however, since I will be taking advantage of the .NET Core CLI commands + CI/CD that targets an Ubuntu environment, I'd like to do something more like:
dotnet msbuild .\MyProject.DB.sqlproj /t:Build /t:Publish /P:SqlPublishProfilePath="./PublishProfiles/MyProject.DB.publish.xml"
In Windows, I immediately get the error:
error MSB4019: The imported project "C:\Program Files\dotnet\sdk\2.1.4\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Basically, what I'm asking is how to successfully build and deploy a SqlProj project in an Ubuntu environment. I've tried Googling, but I have had zero luck thus far. All of the similar issues that I've found were for individuals who were editing their .proj file to target their VS folder's SSDT. All of these individuals were fixing the issue in Windows. This approach will not work in Ubuntu, since the targets file uses Windows registry keys.
EDIT: I'm aware that SSDT is needed in order to perform such a deployment using MSBuild. I've found no evidence that installing/using SSDT is even possible in Ubuntu. If it is not, perhaps there is an alternative solution?
FYI, I'm aware that using a code-first approach with EF Core is possible. I'm attempting to take the raw SP approach (along with leveraging indexes) and keep track of all of my code using SqlProj instead. This will all be stored and CI/CDed from a Git repo.
You can use this NuGet package to deploy without installing SSDT https://www.nuget.org/packages/Microsoft.Data.Tools.Msbuild
I don't know if it will run on Ubuntu or integrate at all with the dotnet cli
My 2020 Solution
I would like to revisit this in 2020 with an updated answer to my original question.
I have taken a different approach to building an deploying SQL Server projects. My current approach is to build a pipeline that uses a vs2017-win2016 agent and use this to build a .dacpac. From there, you build a deployment pipeline to deploy the dacpac (from your artifact drop) out to the SQL Server instance.
This approach better accommodates DevOps methodologies and removes the manual process associated with my previous solution.
You can read more about this here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/apps/aspnet/build-aspnet-dacpac?view=azure-devops
I can't speak to whether or not this will work on Ubuntu, but we recently got through this on a Windows build machine that does not have SSDT installed, using the NuGet package mentioned above. The breakthrough came from piecing together the details in the article below, specifically that using the SDK with MSBuild needed to have environment variables set in order to work.
https://blogs.msdn.microsoft.com/ssdt/2016/08/22/part-5-use-your-own-build-and-deployment-agent/
With that added info, we installed the NuGet package in the root of the solution folder and then wrote a build script in PowerShell. The script sets the environment variables first and then calls MSBuild on the SqlProj file with the appropriate output directory. We don't specifically publish at that point, but instead publish the artifact to Octopus Deploy in our workflow which does the actual deployment.
Again, not sure it will help on Ubuntu, but thought the additional detail might be useful.
As an alternative, it is possible to achieve this with dotnet cli and sqlpackage as explained here using an MSBuild Sdk.
You basically have a database project. Let's call it "DatabaseProject".
You create a new project which is a .NET standard c# library that you can call "DatabaseProject.Build".
Then you can configure you DatabaseProject.Build.csproj as such:
<Project Sdk="MSBuild.Sdk.SqlProj/1.11.4">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Configurations>Debug;Release</Configurations>
</PropertyGroup>
<ItemGroup>
<Content Include="..\DatabaseProject\**\*.sql" />
<Content Remove="..\DatabaseProject\bin\*.sql" />
<Content Remove="..\DatabaseProject\**\*.PostDeployment.sql" />
<PostDeploy Include="..\DatabaseProject\**\*.PostDeployment.sql" />
</ItemGroup>
</Project>
Be Aware The version used V1.11.4 is the one that supports the current .NET SDK shipped with visual studio at the time of the edit of this post. Check out the github repo to get the latest nuget version for your projet.
Using dotnet build will generate a dacpac that you will be able to use with either dotnet publish or sqlpackage.
You can then publish to you SqlServer instance.
If you're like me using a linux runner in your CI, you'll probably need SqlServer authentification method and then run either
sqlpackage /Action:Publish \
/SourceFile:\"DatabaseProject.Build/bin/Debug/netstandard2.0/DatabaseProject.Build.dacpac\" \
/TargetServerName:MyDatabaseServerName \
/TargetDatabaseName:MyDatabaseName \
/TargetUser:Username\
/TargetPassword:Password
or using a profile generated by visual studio :
sqlpackage /Action:Publish /Profile:\"DatabaseProject/PublishProfile/MyProfile.publish.xml\" /SourceFile:\"DatabaseProject.Build/bin/Debug/netstandard2.0/DatabaseProject.Build.dacpac\"
or
dotnet publish /p:TargetServerName=MyServerName /p:TargetDatabaseName=MyDatabseName /p:TargetUser=<username> /p:TargetPassword=<password>
Azure Data Studio now has an extension that lets you build database projects (sqlproj) using the dotnet tool. The brains behind building the project lies in the SQL Server Tools package, which is where the extension gets the required "BuildDirectory" DLL and targets dependencies.
Though not documented, if you want to set this up completely headless outside of Azure Data Studio, you can follow their CLI guide, https://learn.microsoft.com/en-us/sql/azure-data-studio/extensions/sql-database-project-extension-build-from-command-line?view=sql-server-ver15, but instead extract the necessary files from the RHEL release in https://github.com/microsoft/sqltoolsservice/releases and then follow the rest of the extension's documentation. Here is a working Dockerfile that demonstrates the approach:
FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app
RUN apt-get update \
&& apt-get install -y curl
# SSDT dlls and targets file used by Azure Data Studio Extension can be found in the SQL Tools Service project
RUN curl -sSL -o /tmp/sqltools.tar.gz https://github.com/microsoft/sqltoolsservice/releases/download/v3.0.0-release.181/Microsoft.SqlTools.ServiceLayer-rhel-x64-net6.0.tar.gz
# Extract files that are required per https://learn.microsoft.com/en-us/sql/azure-data-studio/extensions/sql-database-project-extension-build-from-command-line?view=sql-server-ver15
RUN mkdir /tmp/sqltools && tar -xzf /tmp/sqltools.tar.gz -C /tmp/sqltools && \
mkdir /app/BuildDirectory && cd /tmp/sqltools && cp \
Microsoft.Data.SqlClient.dll \
Microsoft.Data.Tools.Schema.Sql.dll \
Microsoft.Data.Tools.Schema.SqlTasks.targets \
Microsoft.Data.Tools.Schema.Tasks.Sql.dll \
Microsoft.Data.Tools.Utilities.dll \
Microsoft.SqlServer.Dac.dll \
Microsoft.SqlServer.Dac.Extensions.dll \
Microsoft.SqlServer.TransactSql.ScriptDom.dll \
Microsoft.SqlServer.Types.dll \
System.ComponentModel.Composition.dll \
System.IO.Packaging.dll \
/app/BuildDirectory && \
rm -r /tmp/sqltools
#dotnet build your-database-project.sqlproj /p:NetCoreBuild=true /p:NETCoreTargetsPath="/app/BuildDirectory"
The commented command at the end shows what you could run inside the container in the directory with your database project.
This can also then be combined with a container utilizing sqlpackage to implement a full dacpac build and publish automation toolset.
As mentioned, the easiest way to build DacPac file on a linux agent is done via MSBuild.Sdk.SqlProj
Go to your database project directory in parallel to .sqlproj file create a directory like DB.Build under it create DB.Build.csproj copy.pase the content as below
<Project Sdk="MSBuild.Sdk.SqlProj/1.1.0"> <!-- This will pull in the required tools and dependencies to build a .dacpac with .NET Core -->
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Content Include="..\src\DB\masterdata\**\*.sql" /> <!-- link in the new .csproj to the .sql scripts in your existing database project -->
</ItemGroup>
</Project>
After run you will see dacpac file appears under DB.Build/bin/Release/netstandard2.0/DB.Build.dacpac
Here's my build agent output (Ubuntu agent on Azure devops)
Starting: SQL DB build Release
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.187.0
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
/opt/hostedtoolcache/dotnet/dotnet build /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj -dl:CentralLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"*ForwardingLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" --configuration Release /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=/home/vsts/work/1/recommender-service-cicd/DacPac/
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 51.72 ms for /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj.
Using package name RecommenderAPI.DB.Build and version 1.0.0
Using SQL Server version Sql150
Deleting existing file /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Writing model to /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
RecommenderAPI.DB.Build -> /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/bin/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.71
Finishing: SQL DB build Release
Note: Make sure to restore you NuGet packages in step prior to build

Online-only ClickOnce app not updating through web link

I'm working on a ClickOnce app that's set to online-only. I publish it to an internal IIS server, with an HTML page in the same directory that contains this link:
The deployment looks like so, with all files except the HTML page generated by my project's publish target:
MyAppName
-> Application Files
-> MyAppName_2213_20_0_65
-> <The published files>
-> default.html
-> MyAppName.application
When I click the link, the app runs immediately without any confirmation prompt, and I see from the about box that it's the old version. When I browse to the file share and launch MyAppName.application by double-clicking on it in Explorer, I get the prompt asking me if I'd like to run it, and then it downloads and I get an error:
Unable to install this application because an application with the same identity is already installed. To install this application, either modify the manifest version for this application or uninstall the preexisting application.
As part of the build process, I set the InstallUrl property of the project to http://ourserver/MyAppName/MyAppName.application. Is that wrong? Should it be the HTML page that contains the link? How is it determining the "identity" that's generating a conflict?
Since the app's online-only, it's not installed and doesn't show up in the Programs and Features control panel (and therefore that part of the error message doesn't apply).
I'm new to ClickOnce, so let me know if I left out some helpful information.
Update
If I run mage -cc from a Visual Studio command prompt, the new version launches instead of the old one.
Update 2
As I poked around more, I'm seeing something that looks wrong, and could be the problem. I see the following two lines in my MyAppName.application file (the deployment manifest):
...
<assemblyIdentity name="MyAppName" version="1.0.0.0" ...
...
<dependency>
<dependentAssembly dependencyType="install" codebase="Application Files\MyAppName_2213_20_0_65\MyAppName.exe.manifest" size="82044">
<assemblyIdentity name="MyAppName.exe" version="1.0.0.0" ...
...
You can see the mismatch above. It's deploying to MyAppName_2213_20_0_65, but it thinks the version number of the exe is 1.0.0.0. I'm not sure why it thinks that. My project includes a file that gets generated as part of the build with this line:
[assembly: AssemblyVersion("2213.20.0.65")]
Then, to set the published version number, I have this in my csproj file:
<Target Name="BeforePublish">
<GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
<Output TaskParameter="Assemblies" ItemName="MyAppAssemblyInfo" />
</GetAssemblyIdentity>
<PropertyGroup>
<ApplicationVersion>%(MyAppAssemblyInfo.Version)</ApplicationVersion>
<InstallUrl>$(INSTALL_URL)</InstallUrl>
</PropertyGroup>
</Target>
Does the assembly version listed for my executable even matter? If it does, why is it stuck on 1.0.0.0, and could that be affecting the download of updated versions?
My second update put me on the right track. The problem was indeed the incorrect version number for the assemblyIdentity attributes. To fix it, I'm no longer using a BeforePublish target. Instead, I'm passing in the ApplicationVersion when I call MSBuild:
"%msbuild_path%" MyAppName.csproj /target:Publish /p:ApplicationVersion=%VERSION%

How to sync version numbers for nuget packages when targeting multiple project files

I have a project which has three project files targeting various .net versions (mylib.net20.csproj, mylib.net40.csproj, and mylib.net40-client.csproj). I have a single nuspec file named mylib.nuspec for packaging them all together.
It might help to see the files section of the nuspec file, so here it is:
<files>
<file src="bin\net20\*.dll" target="lib\net20\" />
<file src="bin\net40-client\*.dll" target="lib\net40-client\" />
<file src="bin\net40\*.dll" target="lib\net40\" />
</files>
Right now I use a static version number in the nuspec file and I can successfully package everything by running nuget pack mylib.nuspec. However, I would like to start using $version$ so I don't have to remember to update the version number in two places.
If I simply change the version number to $version$, and build in the same way I get the predictable error:
Attempting to build package from 'mylib.nuspec'.
The replacement token 'version' has no value.
If I use $version$ and package with nuget pack mylib.net40.csproj, it is successful, but I get a package that completely ignores the nuspec file.
Q: What can I do to get the $version$ variable to work?
Technically, I could rename my nuspec file to mylib.net20.nuspec and then package with nuget pack mylib.net20.nuspec. I really don't want to rename my nuspec file in this way though.
creating a package can be done two ways
Using nuspec directly
Using your csproj file , which in fact uses your nuspec file at run time.
First case is pretty straight forward where all metadata defined in nuspec file will be considered for package creation.
nuget pack nuspecfilename.nuspec
On executing above command all hard coded values in your nuspec file will be used for package creation
Above Procedure uses nuspec file directly.
Now let come to your requirement , Using token $version$ in your nuspec files.
In order to work with tokens rather than hard coded values , we need to use csproj file while running nuget pack command.
nuget pack nameofyourprojectfile.csproj -p "configuration=Release;platform=x64"
I'll explain the command i have used ,the concept of using csproj file while generating a package is it will replace all tokens in nuspec file at the run time.
Your corresponding assembly info file to your csproj file will contain required metadata of version which will be replaced at run time.
-p is parameters to be used at run time , here i have assumed that my proj file builds in release and x64 platform so i have passed that at run time so nuget which for artifacts to bundle accordingly.
please refer Here for more details on how to create nuget packages from csproj.
But Ideally when you package from csproj file your nuspec file will be used at run time so ,technically nuspec file should have same name as that of your csproj file.
so requirement of dealing with multiple project files with different frame work may not be achieved with single nuspec file. you need to have individual nuspec accordingly to achieve this.
But if you still want to stick with same nuspec file with out renaming it or making changes to it.
i would suggest passing version at run time
nuget pack nameofnuspec.nuspec -v 1.3.4.5
-v - is version , or you can use -version as well followed by the version of your choice.
after running above command nuget package will be created with the version specified.
to check nuget package created , rename it .zip file and check ...)

Resources