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

Ensure nuget based reference assemblies are created for PowerShell #1152

Closed
raghushantha opened this Issue Jun 20, 2016 · 45 comments

Comments

@raghushantha
Member

raghushantha commented Jun 20, 2016

This is for developers using our SDK

@raghushantha raghushantha added this to the Aug17 milestone Jun 20, 2016

@raghushantha raghushantha self-assigned this Jun 20, 2016

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 20, 2016

Member

What about the existing one, Microsoft.PowerShell.5.ReferenceAssemblies? This is what our cmdlet-example compiles against.

Member

andschwa commented Jun 20, 2016

What about the existing one, Microsoft.PowerShell.5.ReferenceAssemblies? This is what our cmdlet-example compiles against.

@raghushantha

This comment has been minimized.

Show comment
Hide comment
@raghushantha

raghushantha Jun 20, 2016

Member

Existing one stays. We need to have a newer version of the SDK for every release.

Member

raghushantha commented Jun 20, 2016

Existing one stays. We need to have a newer version of the SDK for every release.

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 20, 2016

Member

Are we changing the API?

Member

andschwa commented Jun 20, 2016

Are we changing the API?

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 20, 2016

Member

Hm, we have introduced some PowerShell script variables to the language ($IsWindows, $IsLinux, $IsOSX), but I don't think we've changed the public C# API of the PowerShell classes.

It would probably be better to build reference assemblies out of PowerShell Core. How were the original ones built?

Member

andschwa commented Jun 20, 2016

Hm, we have introduced some PowerShell script variables to the language ($IsWindows, $IsLinux, $IsOSX), but I don't think we've changed the public C# API of the PowerShell classes.

It would probably be better to build reference assemblies out of PowerShell Core. How were the original ones built?

@raghushantha

This comment has been minimized.

Show comment
Hide comment
@raghushantha

raghushantha Jun 20, 2016

Member

@JamesWTruher to answer below:
"How were the original ones built?"

Member

raghushantha commented Jun 20, 2016

@JamesWTruher to answer below:
"How were the original ones built?"

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jul 2, 2016

Member

We are going to need updated (for .NET Core) reference assemblies, and it's blocking #1234.

Member

andschwa commented Jul 2, 2016

We are going to need updated (for .NET Core) reference assemblies, and it's blocking #1234.

@andschwa andschwa assigned JamesWTruher and unassigned raghushantha Jul 2, 2016

@andschwa andschwa modified the milestones: v0.7.0, Aug17 Jul 2, 2016

@vors

This comment has been minimized.

Show comment
Hide comment
@vors

vors Jul 3, 2016

Collaborator

Our reference assemblies will have dependencies on WSMan and MMI assemlbies. We should look, can we turn them into references as well. #1105

Collaborator

vors commented Jul 3, 2016

Our reference assemblies will have dependencies on WSMan and MMI assemlbies. We should look, can we turn them into references as well. #1105

@daxian-dbw

This comment has been minimized.

Show comment
Hide comment
@daxian-dbw

daxian-dbw Jul 3, 2016

Member

MMI and WSMan packages need to have implementation DLLs in them. We won't open source them, so we need the full nuget package to support the WSMan module and WMI/CIM in PowerShell.
As for SMA, I think we also need the full nuget package published eventually, at least for the netstandard1.6 target framework. A third party .NET Core application should be able to host the PowerShell Core SMA.dll, and a full package is required in order to do that.

Member

daxian-dbw commented Jul 3, 2016

MMI and WSMan packages need to have implementation DLLs in them. We won't open source them, so we need the full nuget package to support the WSMan module and WMI/CIM in PowerShell.
As for SMA, I think we also need the full nuget package published eventually, at least for the netstandard1.6 target framework. A third party .NET Core application should be able to host the PowerShell Core SMA.dll, and a full package is required in order to do that.

@vors

This comment has been minimized.

Show comment
Hide comment
@vors

vors Jul 3, 2016

Collaborator

@daxian-dbw full Package for SMA (and others) is already done #930 (comment)
I'm planning to document "how to consume them" in a doc next week.

Collaborator

vors commented Jul 3, 2016

@daxian-dbw full Package for SMA (and others) is already done #930 (comment)
I'm planning to document "how to consume them" in a doc next week.

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jul 3, 2016

Member

@vors we need to figure out how to package that with the Linux version too.

Member

andschwa commented Jul 3, 2016

@vors we need to figure out how to package that with the Linux version too.

@joeyaiello joeyaiello modified the milestones: Future, v0.7.0 Jul 7, 2016

@JamesWTruher

This comment has been minimized.

Show comment
Hide comment
@JamesWTruher

JamesWTruher Oct 5, 2016

Member

The original ones were built in a Razzle environment by taking the original shipping binaries running a couple of tools on them to create reference assemblies. I did this because we wanted to support downlevel releases. If possible, we should create them in our build

Member

JamesWTruher commented Oct 5, 2016

The original ones were built in a Razzle environment by taking the original shipping binaries running a couple of tools on them to create reference assemblies. I did this because we wanted to support downlevel releases. If possible, we should create them in our build

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Mar 31, 2017

Member

We should align this with the PowerShell Standard ref assembly work

Member

SteveL-MSFT commented Mar 31, 2017

We should align this with the PowerShell Standard ref assembly work

@Jaykul

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Jul 16, 2017

Because POWERSHELL DOES. If any library references netcoreapp2.0, then everyone has to -- it's turtles all the way down.

Jaykul commented Jul 16, 2017

Because POWERSHELL DOES. If any library references netcoreapp2.0, then everyone has to -- it's turtles all the way down.

@joeyaiello

This comment has been minimized.

Show comment
Hide comment
@joeyaiello

joeyaiello Aug 1, 2017

Member

Per this Twitter conversation we might be able to become fully netstandard2.0.

In any case, we've known about this problem for a long time, and it's what PowerShell Standard #4374 is intended to solve. We have to do that either way, but it would be nice if the 6.0 SMA.dll could also be netstandard2.0.

Member

joeyaiello commented Aug 1, 2017

Per this Twitter conversation we might be able to become fully netstandard2.0.

In any case, we've known about this problem for a long time, and it's what PowerShell Standard #4374 is intended to solve. We have to do that either way, but it would be nice if the 6.0 SMA.dll could also be netstandard2.0.

@daxian-dbw

This comment has been minimized.

Show comment
Hide comment
@daxian-dbw

daxian-dbw Aug 1, 2017

Member

It's not fully netstandard2.0, restore would fail if the library is used in a runtime that doesn't support RefEmit. BTW, System.Management.Automation still depends on System.Runtime.Loader which is only available in netcoreapp2.0.

Member

daxian-dbw commented Aug 1, 2017

It's not fully netstandard2.0, restore would fail if the library is used in a runtime that doesn't support RefEmit. BTW, System.Management.Automation still depends on System.Runtime.Loader which is only available in netcoreapp2.0.

@lzybkr lzybkr removed their assignment Aug 2, 2017

@Jaykul

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Aug 23, 2017

The point, @daxian-dbw is that your library shouldn't have to know who supports RefEmit, RefEmit knows.

Both System.Runtime.Loader and System.Reflection.Emit are available as nuget packages targeting NetStandard.

Jaykul commented Aug 23, 2017

The point, @daxian-dbw is that your library shouldn't have to know who supports RefEmit, RefEmit knows.

Both System.Runtime.Loader and System.Reflection.Emit are available as nuget packages targeting NetStandard.

@Jaykul

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Sep 12, 2017

So @rkeithhill pointed out PowerShellStandard.Library ...

I noticed it's version 3.0.0-preview-01, and only seems to support PowerShell API for 3.0 (no Information stream, for instance). Is the plan to have versions of this to support each API version, or did someone decide nothing that's been done since 2012 matters?

Jaykul commented Sep 12, 2017

So @rkeithhill pointed out PowerShellStandard.Library ...

I noticed it's version 3.0.0-preview-01, and only seems to support PowerShell API for 3.0 (no Information stream, for instance). Is the plan to have versions of this to support each API version, or did someone decide nothing that's been done since 2012 matters?

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Sep 12, 2017

Member

@Jaykul the current release 3.0.0 aligns with PowerShell 3.0. It's a starting point. We plan to have a 5.x version and probably 6.x.

Member

SteveL-MSFT commented Sep 12, 2017

@Jaykul the current release 3.0.0 aligns with PowerShell 3.0. It's a starting point. We plan to have a 5.x version and probably 6.x.

@powercode

This comment has been minimized.

Show comment
Hide comment
@powercode

powercode Dec 22, 2017

Collaborator

Any progress on this?

I run into issues with IArgumentCompleter when compiling, and problems loading System.Net.Http on Desktop when running against the 3.0.0-preview-01.

Collaborator

powercode commented Dec 22, 2017

Any progress on this?

I run into issues with IArgumentCompleter when compiling, and problems loading System.Net.Http on Desktop when running against the 3.0.0-preview-01.

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Jan 2, 2018

Member

@powercode hoping to have an update on this by next week

Member

SteveL-MSFT commented Jan 2, 2018

@powercode hoping to have an update on this by next week

@JonKohler

This comment has been minimized.

Show comment
Hide comment
@JonKohler

JonKohler Mar 6, 2018

hey @SteveL-MSFT - Any update on this?

JonKohler commented Mar 6, 2018

hey @SteveL-MSFT - Any update on this?

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT
Member

SteveL-MSFT commented Mar 6, 2018

@SteveL-MSFT SteveL-MSFT closed this Mar 6, 2018

@mallochine

This comment has been minimized.

Show comment
Hide comment
@mallochine

mallochine Mar 7, 2018

@SteveL-MSFT sorry if this is obvious -- how to install via the 'nuget' CLI? For some reason Install-Package didn't work but nuget does. E.g. nuget install Newtonsoft.Json

mallochine commented Mar 7, 2018

@SteveL-MSFT sorry if this is obvious -- how to install via the 'nuget' CLI? For some reason Install-Package didn't work but nuget does. E.g. nuget install Newtonsoft.Json

@mallochine

This comment has been minimized.

Show comment
Hide comment
@mallochine

mallochine Mar 7, 2018

oh, nevermind, figured it out. Needed to add -Version or else it doesn't work:

nuget install PowerShellStandard.Library -Version 5.1.0-preview-01

mallochine commented Mar 7, 2018

oh, nevermind, figured it out. Needed to add -Version or else it doesn't work:

nuget install PowerShellStandard.Library -Version 5.1.0-preview-01

@mallochine

This comment has been minimized.

Show comment
Hide comment
@mallochine

mallochine Mar 7, 2018

@SteveL-MSFT another problem -- I noticed the reference assembly installed was net standard 2.0, not 4.5. Thus it didn't compile. What is the correct way to install the right framework?

error CS1070: The type `System.Object' has been forwarded to an assembly that is not referenced. Consider adding a reference to assembly `netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

mallochine commented Mar 7, 2018

@SteveL-MSFT another problem -- I noticed the reference assembly installed was net standard 2.0, not 4.5. Thus it didn't compile. What is the correct way to install the right framework?

error CS1070: The type `System.Object' has been forwarded to an assembly that is not referenced. Consider adding a reference to assembly `netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
@mallochine

This comment has been minimized.

Show comment
Hide comment
@mallochine

mallochine Mar 7, 2018

@SteveL-MSFT so I see that I was supposed to pass in "-sdk:2" flag to 'mcs' compiler to make this work. However, my library uses 'dynamic' language feature, which is not supported in 2.0.

I mean, there must be a way to use the 5.1.0 preview on other release versions, isn't there?

mallochine commented Mar 7, 2018

@SteveL-MSFT so I see that I was supposed to pass in "-sdk:2" flag to 'mcs' compiler to make this work. However, my library uses 'dynamic' language feature, which is not supported in 2.0.

I mean, there must be a way to use the 5.1.0 preview on other release versions, isn't there?

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Mar 8, 2018

Member

@mallochine unfortunately for now, PSStdLib is tied to dotnetstd 2.0.

Member

SteveL-MSFT commented Mar 8, 2018

@mallochine unfortunately for now, PSStdLib is tied to dotnetstd 2.0.

@mallochine

This comment has been minimized.

Show comment
Hide comment
@mallochine

mallochine Mar 8, 2018

what's the github issue we can track to see the cmdlet tied to new sdk?

mallochine commented Mar 8, 2018

what's the github issue we can track to see the cmdlet tied to new sdk?

@Jaykul

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Mar 8, 2018

@mallochine - SteveL said "for now" but it's just to be clear: this isn't really just "for now" -- if you want to write cmdlets that target PowerShell Core, you can't use features that aren't in netstandard2.0. In fact, you must compile targeting .NET Standard 2.0

Additionally, any Windows machines will need at least .NET Framework 4.6.1 (and possibly 4.7, depending on features you use) if you want to be sure the module will work in full desktop "Windows PowerShell" ...

You can cross-compile (producing separate assemblies targeting each framework), but your code still has to compile against .NET Standard 2.0 to work in PowerShell Core.

Jaykul commented Mar 8, 2018

@mallochine - SteveL said "for now" but it's just to be clear: this isn't really just "for now" -- if you want to write cmdlets that target PowerShell Core, you can't use features that aren't in netstandard2.0. In fact, you must compile targeting .NET Standard 2.0

Additionally, any Windows machines will need at least .NET Framework 4.6.1 (and possibly 4.7, depending on features you use) if you want to be sure the module will work in full desktop "Windows PowerShell" ...

You can cross-compile (producing separate assemblies targeting each framework), but your code still has to compile against .NET Standard 2.0 to work in PowerShell Core.

@mallochine

This comment has been minimized.

Show comment
Hide comment
@mallochine

mallochine Mar 9, 2018

Ok, so turns out actually .NET Standard and .NET Framework at different things. I finally got this to compile.

How do I install .NET Core 2.0 SDK from nuget? Since the library I used was deprecated -- https://www.nuget.org/packages/NETStandard.Library.NETFramework/2.0.0-preview2-25405-01

mallochine commented Mar 9, 2018

Ok, so turns out actually .NET Standard and .NET Framework at different things. I finally got this to compile.

How do I install .NET Core 2.0 SDK from nuget? Since the library I used was deprecated -- https://www.nuget.org/packages/NETStandard.Library.NETFramework/2.0.0-preview2-25405-01

@darkonejr

This comment has been minimized.

Show comment
Hide comment
@darkonejr

darkonejr Mar 9, 2018

Is this truly based on PowerShell 5.1? Or is this just renamed from the original PowerShell 3 version? I don't see SMA.Runspace.CreatePipeline() for instance.

darkonejr commented Mar 9, 2018

Is this truly based on PowerShell 5.1? Or is this just renamed from the original PowerShell 3 version? I don't see SMA.Runspace.CreatePipeline() for instance.

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Mar 10, 2018

Member

@darkonejr PowerShell Standard Library intends to always be forward compatible. As such, PS Std Lib v3 is a subset of PS v3 where the apis still exist in PSCore6. Similarly , PS Std lib v5.1 is a subset of PS v5.1 where the apis still exist in PSCore6 (essentially, some exceptions). I would expect CreatePipeline() to still be there. If its not, it's probably a bug in the preview. I would suggest opening a new issue for any APIs you expect to be there, but aren't.

Member

SteveL-MSFT commented Mar 10, 2018

@darkonejr PowerShell Standard Library intends to always be forward compatible. As such, PS Std Lib v3 is a subset of PS v3 where the apis still exist in PSCore6. Similarly , PS Std lib v5.1 is a subset of PS v5.1 where the apis still exist in PSCore6 (essentially, some exceptions). I would expect CreatePipeline() to still be there. If its not, it's probably a bug in the preview. I would suggest opening a new issue for any APIs you expect to be there, but aren't.

@SteveL-MSFT SteveL-MSFT moved this from Priority-High to Done in Developer Experience/SDK Mar 18, 2018

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