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.

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

Cannot package library targeting .Net Standard correctly #3108

Closed
huoyaoyuan opened this Issue Jul 11, 2016 · 14 comments

Comments

Projects
None yet
6 participants
@huoyaoyuan

huoyaoyuan commented Jul 11, 2016

The project and project.json is generated by the option "Target .Net Standard Platform" in Visual Studio.
In csproj:

<TargetFrameworkProfile>
</TargetFrameworkProfile> 
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>

and in project.json:

{
  "supports": {},
  "dependencies": {
    "Microsoft.NETCore.Portable.Compatibility": "1.0.1",
    "NETStandard.Library": "1.6.0"
  },
  "frameworks": {
    "netstandard1.0": {}
  }
}

When packaging the project, there will be a "portable50" folder. Nuget 3.4.4 warns "invald framework folder", 3.5beta2 doesn't warn, but the folder name is the same.

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jul 11, 2016

Contributor

@huoyaoyuan what version of Visual Studio are you using?

Contributor

emgarten commented Jul 11, 2016

@huoyaoyuan what version of Visual Studio are you using?

@huoyaoyuan

This comment has been minimized.

Show comment
Hide comment
@huoyaoyuan

huoyaoyuan Jul 12, 2016

@emgarten Visual Studio 2015 Update 3, the latest version.

huoyaoyuan commented Jul 12, 2016

@emgarten Visual Studio 2015 Update 3, the latest version.

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Jul 12, 2016

Contributor

@huoyaoyuan - sounds like 3.5.0-beta2 has fixed your issue, but 3.4.4 (an older version) had a problem.
If that is the case, you'll be happy with 3.5.0 when it releases.
Please reopen if I misinterpreted?

Contributor

rrelyea commented Jul 12, 2016

@huoyaoyuan - sounds like 3.5.0-beta2 has fixed your issue, but 3.4.4 (an older version) had a problem.
If that is the case, you'll be happy with 3.5.0 when it releases.
Please reopen if I misinterpreted?

@rrelyea rrelyea closed this Jul 12, 2016

@huoyaoyuan

This comment has been minimized.

Show comment
Hide comment
@huoyaoyuan

huoyaoyuan Jul 12, 2016

@rrelyea 3.5.0-beta2 just does not warn, but the folder name is still "portable50". According to .Net Standard documentation, the corresponding folder name should be "netstandard1.0". I'm not sure whether "portable50" works or not.

huoyaoyuan commented Jul 12, 2016

@rrelyea 3.5.0-beta2 just does not warn, but the folder name is still "portable50". According to .Net Standard documentation, the corresponding folder name should be "netstandard1.0". I'm not sure whether "portable50" works or not.

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jul 12, 2016

Contributor

@huoyaoyuan try the latest nightly build from: http://dist.nuget.org/index.html

NuGet 3.4.4 does not support packing project.json and 3.5.0-beta2 may have limited support compared to the latest build. From what you are describing it looks like the project.json file isn't being used when you create the package.

Contributor

emgarten commented Jul 12, 2016

@huoyaoyuan try the latest nightly build from: http://dist.nuget.org/index.html

NuGet 3.4.4 does not support packing project.json and 3.5.0-beta2 may have limited support compared to the latest build. From what you are describing it looks like the project.json file isn't being used when you create the package.

@huoyaoyuan

This comment has been minimized.

Show comment
Hide comment
@huoyaoyuan

huoyaoyuan Jul 12, 2016

@emgarten the issue still exists in the latest nightly build. Still "portable50". Another issue of not applying .nuspec seems fixed.

huoyaoyuan commented Jul 12, 2016

@emgarten the issue still exists in the latest nightly build. Still "portable50". Another issue of not applying .nuspec seems fixed.

@ipjohnson

This comment has been minimized.

Show comment
Hide comment
@ipjohnson

ipjohnson Jul 13, 2016

I've run into the same issue, it does look like the project.json file is used correctly as the package that is generated has the correct .netstandard1.0 dependencies. The problem seems to be the dll is being placed in the lib/portable50 directory rather than lib/netstandard1.0

ipjohnson commented Jul 13, 2016

I've run into the same issue, it does look like the project.json file is used correctly as the package that is generated has the correct .netstandard1.0 dependencies. The problem seems to be the dll is being placed in the lib/portable50 directory rather than lib/netstandard1.0

@emgarten emgarten reopened this Jul 13, 2016

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jul 13, 2016

Contributor

@ipjohnson thanks for the update, this looks like a bug in pack. The framework from project.json should be used.

Contributor

emgarten commented Jul 13, 2016

@ipjohnson thanks for the update, this looks like a bug in pack. The framework from project.json should be used.

@ipjohnson

This comment has been minimized.

Show comment
Hide comment
@ipjohnson

ipjohnson Jul 13, 2016

@emgarten thanks for the quick reply, do you have any guidance on working around this?

ipjohnson commented Jul 13, 2016

@emgarten thanks for the quick reply, do you have any guidance on working around this?

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jul 13, 2016

Contributor

@ipjohnson try nuget.exe pack <project.json>

Contributor

emgarten commented Jul 13, 2016

@ipjohnson try nuget.exe pack <project.json>

@ipjohnson

This comment has been minimized.

Show comment
Hide comment
@ipjohnson

ipjohnson Jul 13, 2016

@emgarten I get the following error

Attempting to build package from 'project.json'.
Object reference not set to an instance of an object.

ipjohnson commented Jul 13, 2016

@emgarten I get the following error

Attempting to build package from 'project.json'.
Object reference not set to an instance of an object.

@BladeWise

This comment has been minimized.

Show comment
Hide comment
@BladeWise

BladeWise Jul 14, 2016

@emgarten @rrelyea Using the NuGet.exe nightly build (3.5.1.1597) nuget pack <projectname>.csproj still places dll files inside portable50 folder.
Moreover, using pack over the <projectname>.project.json is not a valid solution, since we cannot achieve the same results as before.

Ona a side note: using <projectname>.csproj, <projectname>.nuspec, packages.<projectname>.config and calling nuget pack <projectname>.csproj generates a package listing required dependencies and with substitution tokens (i.e. $version$, $author$) properly resolved. Moreover, using option -includereferencedprojects would append package dependencies for project references that have corresponding nuspec.
Will this scenario still be supported using <projectname>.csproj, <projectname>.nuspec, <projectname>.project.json and calling nuget pack <projectname>.csproj?

BladeWise commented Jul 14, 2016

@emgarten @rrelyea Using the NuGet.exe nightly build (3.5.1.1597) nuget pack <projectname>.csproj still places dll files inside portable50 folder.
Moreover, using pack over the <projectname>.project.json is not a valid solution, since we cannot achieve the same results as before.

Ona a side note: using <projectname>.csproj, <projectname>.nuspec, packages.<projectname>.config and calling nuget pack <projectname>.csproj generates a package listing required dependencies and with substitution tokens (i.e. $version$, $author$) properly resolved. Moreover, using option -includereferencedprojects would append package dependencies for project references that have corresponding nuspec.
Will this scenario still be supported using <projectname>.csproj, <projectname>.nuspec, <projectname>.project.json and calling nuget pack <projectname>.csproj?

@ipjohnson

This comment has been minimized.

Show comment
Hide comment
@ipjohnson

ipjohnson Jul 19, 2016

@emgarten maybe I'm missing something but this seems like a rather large stumbling block for getting open source package developers to move to .netstandard. Should we not be using the "Target .NET Platform Standard" link in VS and create the projects by hand with xsproj files?

ipjohnson commented Jul 19, 2016

@emgarten maybe I'm missing something but this seems like a rather large stumbling block for getting open source package developers to move to .netstandard. Should we not be using the "Target .NET Platform Standard" link in VS and create the projects by hand with xsproj files?

@emgarten

This comment has been minimized.

Show comment
Hide comment
@emgarten

emgarten Jul 19, 2016

Contributor

@ipjohnson agreed, this looks like a critical bug in pack for project.json that should be fixed for the upcoming release.

Contributor

emgarten commented Jul 19, 2016

@ipjohnson agreed, this looks like a critical bug in pack for project.json that should be fixed for the upcoming release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment