C# 8 support and folder requirement

[markm77]

Hi there,

I adjusted a .csproj generated from dotnet new psmodule to support C# 8 and nullable:

    <TargetFramework>netstandard2.1</TargetFramework>
    <Nullable>enable</Nullable>

with no seeming ill effects in PowerShell Core 7.

Is that supported/reasonable either for the current 5.1 or upcoming 7.0 version of PowerShellStandard? (Basically I don't need Windows PowerShell support but using PowerShellStandard and the template seemed the best way to start a new project.)

Secondly will the upcoming PowerShellStandard 7.0 allow a difference between the DLL base name and project folder name as "well-formed" requirements of Windows PowerShell are no longer relevant? This would enable me to avoid the choice between a snappy DLL name or proper namespace-based project folder name.

BR, Mark

[SeeminglyScience]

Is that supported/reasonable either for the current 5.1 or upcoming 7.0 version of PowerShellStandard? (Basically I don't need Windows PowerShell support but using PowerShellStandard and the template seemed the best way to start a new project.)

With the 7.0 version I don't see a reason not to default to netstandard2.1. Can't for 5.1 though, afaik net framework doesn't plan to ever implement 2.1.

Enabling nullable reference types by default would create a lot of confusion though. At least until this reference lib gets nullability annotations (assuming the PowerShell repo even has them yet).

Secondly will the upcoming PowerShellStandard 7.0 allow a difference between the DLL base name and project folder name as "well-formed" requirements of Windows PowerShell are no longer relevant? This would enable me to avoid the choice between a snappy DLL name or proper namespace-based project folder name.

Can you provide an example of what you mean? From a project compilation perspective, it doesn't care about the folder name and how it relates to your assembly name afaik. If you mean from a module import perspective, you can name your assembly whatever you want as long as you have a manifest that tells PowerShell what your root module is.

[markm77]

Thanks for the reply, appreciated.

Enabling nullable reference types by default would create a lot of confusion though. At least until this reference lib gets nullability annotations (assuming the PowerShell repo even has them yet).

It seems to work okay as long as configuring System.Management.Automation to catch unwanted parameter nulls (and using run-time guards just in case this code gets changed). I guess it's the same as using NRT with any non-NRT dependency - you need to be careful on the interface. Corrections welcome if I'm missing something though.

Can you provide an example of what you mean?

If I have project folder x containing y.csproj which produces z.dll in its bin folder I thought x and z had to be the same create a "well-formed" module (https://docs.microsoft.com/en-us/powershell/scripting/developer/module/installing-a-powershell-module?view=powershell-7). From what you say though I can specify my assembly name as z2 in the manifest (thanks for info) which can be different from z but again does that still mean z2 must match x? I would like x to be independent of z/z2 and still have module import work.

[SeeminglyScience]

It seems to work okay as long as configuring System.Management.Automation to catch unwanted parameter nulls (and using run-time guards just in case this code gets changed). I guess it's the same as using NRT with any non-NRT dependency - you need to be careful on the interface. Corrections welcome if I'm missing something though.

Yeah it works okay, I do it on my own projects. However if you aren't already familiar with the potential pitfalls and required workarounds of enabling NRT when your main dependency isn't annotated (or likely what NRT is period), it's gonna get real confusing. I'd definitely recommend folks adopt NRT, I just don't think it makes sense a default at least until the lib is annotated.

If I have project folder x containing y.csproj which produces z.dll in its bin folder I thought x and z had to be the same create a "well-formed" module (https://docs.microsoft.com/en-us/powershell/scripting/developer/module/installing-a-powershell-module?view=powershell-7). From what you say though I can specify my assembly name as z2 in the manifest (thanks for info) which can be different from z but again does that still mean z2 must match x? I would like x to be independent of z/z2 and still have module import work.

So for a module to imported the folder structure has to look like this:

└───$env:PSModulePath
    └───MyModuleName
        └───1.0.0
                MyModuleName.psd1
                Something.AnotherThing.Project.dll

The above assumes that MyModuleName.psd1 has a RootModule entry of Something.AnotherThing.Project.dll or points to a psm1 that manually imports the DLL.

If you wanted to skip the manifest (which there isn't really a good reason to do tbh and will just cause more problems in the long run) then the name would be important and would need to be something like:

└───$env:PSModulePath
    └───MyModuleName
        └───1.0.0
                MyModuleName.dll

Typically though, I'd still recommend keeping the assembly name the same as your module name, but nothing is gonna force ya.

Also for the record, this repo is purely the reference library and the dotnet new template. If you have a suggestion for a change in behavior, you'll want to file that over at PowerShell/PowerShell.

[markm77]

@SeeminglyScience Just wanted to say thanks for this helpful information, much appreciated. I'll close this issue now.