How to properly dynamically change NuGet PackageId and dependency PackageId at build time?
We have an internal convention where if the CI/CD is doing a feature branch build, the NuGet package should be publish as "PackageId-FeatureBranchName". We publish these packages to a special feed that we don't reference in production builds. In our build script, if we detect we are doing a feature branch build, we look for any .nuspec files output by the build and the build would replace in the .nuspec file "" with "-FeatureBranchName" in all .nuspec files in the solution. This works fine if there is only one package with no dependencies on other projects in the solution.
Now I have two .NET Standard projects My.Assmebly.A and My.Assmebly.B that need to have their own NuGet packages. B depends on A. I am able to use the same build script above to set the of each package correctly. However, I am not sure of a solution to also update the .nuspec for package B to also update it's dependency on A to have the renamed My.Assmebly.A-FeatureBranchName.
Is there an easy way to script this. Or, I feel like I'm not doing this in the correct way with dotnet pack but I don't see any way to set package ids through command line or other, specifically when it comes to dependencies like this. I do see the $id$ token you can setup and replace. But I'm not sure how to use this now that .NET Standard projects generate their own .nuspec during the build. Nor do I think this will work with my dependency situation.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Needs to look like this:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B-FeatureBranchName</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A-FeatureBranchName" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
.net .net-core nuget nuget-package .net-standard
add a comment |
We have an internal convention where if the CI/CD is doing a feature branch build, the NuGet package should be publish as "PackageId-FeatureBranchName". We publish these packages to a special feed that we don't reference in production builds. In our build script, if we detect we are doing a feature branch build, we look for any .nuspec files output by the build and the build would replace in the .nuspec file "" with "-FeatureBranchName" in all .nuspec files in the solution. This works fine if there is only one package with no dependencies on other projects in the solution.
Now I have two .NET Standard projects My.Assmebly.A and My.Assmebly.B that need to have their own NuGet packages. B depends on A. I am able to use the same build script above to set the of each package correctly. However, I am not sure of a solution to also update the .nuspec for package B to also update it's dependency on A to have the renamed My.Assmebly.A-FeatureBranchName.
Is there an easy way to script this. Or, I feel like I'm not doing this in the correct way with dotnet pack but I don't see any way to set package ids through command line or other, specifically when it comes to dependencies like this. I do see the $id$ token you can setup and replace. But I'm not sure how to use this now that .NET Standard projects generate their own .nuspec during the build. Nor do I think this will work with my dependency situation.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Needs to look like this:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B-FeatureBranchName</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A-FeatureBranchName" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
.net .net-core nuget nuget-package .net-standard
add a comment |
We have an internal convention where if the CI/CD is doing a feature branch build, the NuGet package should be publish as "PackageId-FeatureBranchName". We publish these packages to a special feed that we don't reference in production builds. In our build script, if we detect we are doing a feature branch build, we look for any .nuspec files output by the build and the build would replace in the .nuspec file "" with "-FeatureBranchName" in all .nuspec files in the solution. This works fine if there is only one package with no dependencies on other projects in the solution.
Now I have two .NET Standard projects My.Assmebly.A and My.Assmebly.B that need to have their own NuGet packages. B depends on A. I am able to use the same build script above to set the of each package correctly. However, I am not sure of a solution to also update the .nuspec for package B to also update it's dependency on A to have the renamed My.Assmebly.A-FeatureBranchName.
Is there an easy way to script this. Or, I feel like I'm not doing this in the correct way with dotnet pack but I don't see any way to set package ids through command line or other, specifically when it comes to dependencies like this. I do see the $id$ token you can setup and replace. But I'm not sure how to use this now that .NET Standard projects generate their own .nuspec during the build. Nor do I think this will work with my dependency situation.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Needs to look like this:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B-FeatureBranchName</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A-FeatureBranchName" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
.net .net-core nuget nuget-package .net-standard
We have an internal convention where if the CI/CD is doing a feature branch build, the NuGet package should be publish as "PackageId-FeatureBranchName". We publish these packages to a special feed that we don't reference in production builds. In our build script, if we detect we are doing a feature branch build, we look for any .nuspec files output by the build and the build would replace in the .nuspec file "" with "-FeatureBranchName" in all .nuspec files in the solution. This works fine if there is only one package with no dependencies on other projects in the solution.
Now I have two .NET Standard projects My.Assmebly.A and My.Assmebly.B that need to have their own NuGet packages. B depends on A. I am able to use the same build script above to set the of each package correctly. However, I am not sure of a solution to also update the .nuspec for package B to also update it's dependency on A to have the renamed My.Assmebly.A-FeatureBranchName.
Is there an easy way to script this. Or, I feel like I'm not doing this in the correct way with dotnet pack but I don't see any way to set package ids through command line or other, specifically when it comes to dependencies like this. I do see the $id$ token you can setup and replace. But I'm not sure how to use this now that .NET Standard projects generate their own .nuspec during the build. Nor do I think this will work with my dependency situation.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Needs to look like this:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B-FeatureBranchName</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A-FeatureBranchName" version="1.0.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
.net .net-core nuget nuget-package .net-standard
.net .net-core nuget nuget-package .net-standard
edited Nov 20 '18 at 13:02
Dude0001
asked Nov 15 '18 at 15:11
Dude0001Dude0001
91211025
91211025
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Don't change the name of the assembly. The correct thing to do is to add the branch name to the version number using the version-suffix parameter. This removes the need for you to search and edit any .nuspec files to force your naming convention.
You can pack your assembly by running:
dotnet pack --version-suffix [branchname]
replacing [branchname] with the correct value.
You library would be published as:
name: My.Assembly.A
version: 1.0.0-FeatureBranchName
If you add a version-suffix to your version then this will also cause the packages to be listed as pre-release in the nuget package manager.
You can also use version-ranges in your dependency list to always get a specific version.
See this link for the official documentation.
But, in essence, you can define your dependency as:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.*" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Package B will now depend on the latest My.Assembly.A in your package feed. If you publish them together then they should (in theory) stay in sync.
We aren't renaming the assembly, just the NuGet package id. They don't have to match. I am investigating using the approach you mention as that seems to be the built in way to do what we are doing which was one of the solutions I was looking for.
– Dude0001
Nov 27 '18 at 19:38
My bad. I meant to saypackage id:-(
– Simply Ged
Nov 27 '18 at 21:04
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322449%2fhow-to-properly-dynamically-change-nuget-packageid-and-dependency-packageid-at-b%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Don't change the name of the assembly. The correct thing to do is to add the branch name to the version number using the version-suffix parameter. This removes the need for you to search and edit any .nuspec files to force your naming convention.
You can pack your assembly by running:
dotnet pack --version-suffix [branchname]
replacing [branchname] with the correct value.
You library would be published as:
name: My.Assembly.A
version: 1.0.0-FeatureBranchName
If you add a version-suffix to your version then this will also cause the packages to be listed as pre-release in the nuget package manager.
You can also use version-ranges in your dependency list to always get a specific version.
See this link for the official documentation.
But, in essence, you can define your dependency as:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.*" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Package B will now depend on the latest My.Assembly.A in your package feed. If you publish them together then they should (in theory) stay in sync.
We aren't renaming the assembly, just the NuGet package id. They don't have to match. I am investigating using the approach you mention as that seems to be the built in way to do what we are doing which was one of the solutions I was looking for.
– Dude0001
Nov 27 '18 at 19:38
My bad. I meant to saypackage id:-(
– Simply Ged
Nov 27 '18 at 21:04
add a comment |
Don't change the name of the assembly. The correct thing to do is to add the branch name to the version number using the version-suffix parameter. This removes the need for you to search and edit any .nuspec files to force your naming convention.
You can pack your assembly by running:
dotnet pack --version-suffix [branchname]
replacing [branchname] with the correct value.
You library would be published as:
name: My.Assembly.A
version: 1.0.0-FeatureBranchName
If you add a version-suffix to your version then this will also cause the packages to be listed as pre-release in the nuget package manager.
You can also use version-ranges in your dependency list to always get a specific version.
See this link for the official documentation.
But, in essence, you can define your dependency as:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.*" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Package B will now depend on the latest My.Assembly.A in your package feed. If you publish them together then they should (in theory) stay in sync.
We aren't renaming the assembly, just the NuGet package id. They don't have to match. I am investigating using the approach you mention as that seems to be the built in way to do what we are doing which was one of the solutions I was looking for.
– Dude0001
Nov 27 '18 at 19:38
My bad. I meant to saypackage id:-(
– Simply Ged
Nov 27 '18 at 21:04
add a comment |
Don't change the name of the assembly. The correct thing to do is to add the branch name to the version number using the version-suffix parameter. This removes the need for you to search and edit any .nuspec files to force your naming convention.
You can pack your assembly by running:
dotnet pack --version-suffix [branchname]
replacing [branchname] with the correct value.
You library would be published as:
name: My.Assembly.A
version: 1.0.0-FeatureBranchName
If you add a version-suffix to your version then this will also cause the packages to be listed as pre-release in the nuget package manager.
You can also use version-ranges in your dependency list to always get a specific version.
See this link for the official documentation.
But, in essence, you can define your dependency as:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.*" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Package B will now depend on the latest My.Assembly.A in your package feed. If you publish them together then they should (in theory) stay in sync.
Don't change the name of the assembly. The correct thing to do is to add the branch name to the version number using the version-suffix parameter. This removes the need for you to search and edit any .nuspec files to force your naming convention.
You can pack your assembly by running:
dotnet pack --version-suffix [branchname]
replacing [branchname] with the correct value.
You library would be published as:
name: My.Assembly.A
version: 1.0.0-FeatureBranchName
If you add a version-suffix to your version then this will also cause the packages to be listed as pre-release in the nuget package manager.
You can also use version-ranges in your dependency list to always get a specific version.
See this link for the official documentation.
But, in essence, you can define your dependency as:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>My.Assmebly.B</id>
<dependencies>
<group targetFramework=".NETCoreApp2.1">
<dependency id="My.Assmebly.A" version="1.0.*" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
Package B will now depend on the latest My.Assembly.A in your package feed. If you publish them together then they should (in theory) stay in sync.
answered Nov 21 '18 at 3:26
Simply GedSimply Ged
2,70621525
2,70621525
We aren't renaming the assembly, just the NuGet package id. They don't have to match. I am investigating using the approach you mention as that seems to be the built in way to do what we are doing which was one of the solutions I was looking for.
– Dude0001
Nov 27 '18 at 19:38
My bad. I meant to saypackage id:-(
– Simply Ged
Nov 27 '18 at 21:04
add a comment |
We aren't renaming the assembly, just the NuGet package id. They don't have to match. I am investigating using the approach you mention as that seems to be the built in way to do what we are doing which was one of the solutions I was looking for.
– Dude0001
Nov 27 '18 at 19:38
My bad. I meant to saypackage id:-(
– Simply Ged
Nov 27 '18 at 21:04
We aren't renaming the assembly, just the NuGet package id. They don't have to match. I am investigating using the approach you mention as that seems to be the built in way to do what we are doing which was one of the solutions I was looking for.
– Dude0001
Nov 27 '18 at 19:38
We aren't renaming the assembly, just the NuGet package id. They don't have to match. I am investigating using the approach you mention as that seems to be the built in way to do what we are doing which was one of the solutions I was looking for.
– Dude0001
Nov 27 '18 at 19:38
My bad. I meant to say
package id :-(– Simply Ged
Nov 27 '18 at 21:04
My bad. I meant to say
package id :-(– Simply Ged
Nov 27 '18 at 21:04
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322449%2fhow-to-properly-dynamically-change-nuget-packageid-and-dependency-packageid-at-b%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown