Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

dotnet pack should pack tools with the versions that the package was built against #4063

Closed
livarcocc opened this issue Dec 7, 2016 · 5 comments
Closed

dotnet pack should pack tools with the versions that the package was built against #4063

livarcocc opened this issue Dec 7, 2016 · 5 comments
Assignees
@rohit21agrawal
Labels
Functionality:Pack Type:Bug
Milestone
4.0 RC3

Comments

@livarcocc
Copy link

This is for a situation where I have a library (or tool) that has a * dependency, like on Microsoft.DotNet.Cli.Utils: 1.0.0-preview4-*.

Today, the nuspec for this package gets generated with 1.0.0-preview4-, which means that when the tool gets restored, we end up with the lowest version of Cli.Utils, no matter what.

Instead, when the nuspec gets generated by pack, it should set the * versions to those in the project.assets.json file of the project being packaged.

I believe this used to be the behavior for project.json, so, in a way, we lost parity with it.

Also, we just hit this in the CLI itself and it was a bit of a pain to debug and understand all this.

cc @piotrp @emgartem @rrelyea
@davidfowl
Copy link
Member

Yes that needs to work (pretty big regression otherwise)

livarcocc pushed a commit to livarcocc/cli-1 that referenced this issue Dec 7, 2016
Adding a SdkNugetVersion property when invoking dotnet pack on test p…
c48867b 
…ackages so that test packages can reference exact packages. We need that because of NuGet/Home#4063. Without it, pack creates the nuspec with a version like 1.0.0-version-, instead of 1.0.0-version-<version_used_in_build>, which leads to problems when restoring the tool. Like, it ends up restoring to the closest version of the package (oldest), instead of the latest.
@livarcocc livarcocc mentioned this issue Dec 7, 2016
Merged
@rrelyea rrelyea added this to the 4.0 RC3 milestone Dec 8, 2016
livarcocc added a commit to livarcocc/cli-1 that referenced this issue Dec 8, 2016
@livarcocc
Merge branch 'rel/1.0.0-preview4' into merge_preview4
fd70498 
* rel/1.0.0-preview4:
  Adding MigrateWebSdkRule to the DefaultMigrationRuleSet (dotnet#4963)
  MSBuild to 15.1.458 (dotnet#4950)
  Update web template for Web SDK 154 (dotnet#4948)
  Adding a SdkNugetVersion property when invoking dotnet pack on test packages so that test packages can reference exact packages. We need that because of NuGet/Home#4063. Without it, pack creates the nuspec with a version like 1.0.0-version-, instead of 1.0.0-version-<version_used_in_build>, which leads to problems when restoring the tool. Like, it ends up restoring to the closest version of the package (oldest), instead of the latest.
  remove unused directories from bundled sdks
  fix mstest package version, aligned to c#
  align f# web template
  align f# xunit template
  align f# mstest template
  align f# lib template
  align f# console proj
  bundle fsharp sdk, only Sdk directory is required
  Add more xlf files for new strings
  Updating the preview4 channel to rel-1.0.0-preview4
TheRealPiotrP pushed a commit to dotnet/cli that referenced this issue Dec 9, 2016
Merge rel/1.0.0-preview4 back into rel/1.0.0 (#4974)
1fd99f1 
* Updating the preview4 channel to rel-1.0.0-preview4

* Add more xlf files for new strings

* bundle fsharp sdk, only Sdk directory is required

* align f# console proj

* align f# lib template

* align f# mstest template

* align f# xunit template

* align f# web template

* fix mstest package version, aligned to c#

* remove unused directories from bundled sdks

* Adding a SdkNugetVersion property when invoking dotnet pack on test packages so that test packages can reference exact packages. We need that because of NuGet/Home#4063. Without it, pack creates the nuspec with a version like 1.0.0-version-, instead of 1.0.0-version-<version_used_in_build>, which leads to problems when restoring the tool. Like, it ends up restoring to the closest version of the package (oldest), instead of the latest.

* Update web template for Web SDK 154 (#4948)

* Update WebSDK version

* Update web template to get rid of globs

aspnet/Templates#735

* MSBuild to 15.1.458 (#4950)

* Adding MigrateWebSdkRule to the DefaultMigrationRuleSet (#4963)

* Adding MigrateWebSdkRule to the DefaultMigrationRuleSet and adding a E2E test to cover it.

* Do not migrate compile and EmbeddedResources for web application, because those are included in the Web Sdk already.

* Addressing code review comments
@natemcmaster
Copy link

Is there any way we can workaround this in RC.2 bits? If not, this will likely cause major pain while trying to upgrade aspnet to vs2017. We liberally use floating versions e.g. 1.2.0-*, but the nuspec contains 1.2.0-- on pack.

@natemcmaster
Copy link

Workaround for RC.2: add this to your project

    <Target Name="ResolveRestoredPackageVersions"
            BeforeTargets="GenerateNuspec"
            DependsOnTargets="ResolvePackageDependenciesDesignTime"
            Condition="'$(TargetFramework)'!=''">

        <ItemGroup>
            <_FloatingVersions Include="@(_PackageReferences)" Condition="$([System.String]::new('%(Version)').EndsWith('*'))" />
            <_ResolvedFloatingVersion Include="@(_FloatingVersions)">
                <ResolvedName>%(_DependenciesDesignTime.Name)</ResolvedName>
                <Version>%(_DependenciesDesignTime.Version)</Version>
            </_ResolvedFloatingVersion>
            <_PackageReferences Remove="@(_PackageReferences)" Condition="$([System.String]::new('%(Version)').EndsWith('*'))" />
            <_PackageReferences Include="@(_ResolvedFloatingVersion)" Condition="'%(Identity)'=='%(_ResolvedFloatingVersion.ResolvedName)'" />
        </ItemGroup>
    </Target>

This was referenced Dec 16, 2016
Merged
Closed
mlorbetske pushed a commit to mlorbetske/cli that referenced this issue Dec 18, 2016
Merge rel/1.0.0-preview4 back into rel/1.0.0 (dotnet#4974)
094f1d1 
* Updating the preview4 channel to rel-1.0.0-preview4

* Add more xlf files for new strings

* bundle fsharp sdk, only Sdk directory is required

* align f# console proj

* align f# lib template

* align f# mstest template

* align f# xunit template

* align f# web template

* fix mstest package version, aligned to c#

* remove unused directories from bundled sdks

* Adding a SdkNugetVersion property when invoking dotnet pack on test packages so that test packages can reference exact packages. We need that because of NuGet/Home#4063. Without it, pack creates the nuspec with a version like 1.0.0-version-, instead of 1.0.0-version-<version_used_in_build>, which leads to problems when restoring the tool. Like, it ends up restoring to the closest version of the package (oldest), instead of the latest.

* Update web template for Web SDK 154 (dotnet#4948)

* Update WebSDK version

* Update web template to get rid of globs

aspnet/Templates#735

* MSBuild to 15.1.458 (dotnet#4950)

* Adding MigrateWebSdkRule to the DefaultMigrationRuleSet (dotnet#4963)

* Adding MigrateWebSdkRule to the DefaultMigrationRuleSet and adding a E2E test to cover it.

* Do not migrate compile and EmbeddedResources for web application, because those are included in the Web Sdk already.

* Addressing code review comments
@rrelyea
Copy link
Contributor

rrelyea commented Jan 3, 2017 •
edited
Loading

@rohit21agrawal - please get your head around this. raised as a blocking issue by asp.net team. (note there is a workaround)

@rohit21agrawal
Copy link
Contributor

@rrelyea i already have a fix for this, this will be fixed in RC3.

@rohit21agrawal rohit21agrawal mentioned this issue Jan 4, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rohit21agrawal rohit21agrawal

Labels
Functionality:Pack Type:Bug
Projects
None yet
Milestone
4.0 RC3
Development

No branches or pull requests
5 participants
@davidfowl @livarcocc @rohit21agrawal @natemcmaster @rrelyea