search

AArnott / Library.Template

A template for a NuGet package with tests, stylecop, fxcop, versioning, and Azure Pipelines build ready to go.
MIT License
131 stars 26 forks source link

Expand-template.ps1 tries to find Windows only paths when running on Linux #73

Closed GeeWee closed 4 years ago

GeeWee commented 4 years ago

When running expand-templates.ps1 on a linux machine via powershell core, I get the following output.

pwsh Expand-Template.ps1

cmdlet Expand-Template.ps1 at command pipeline position 1
Supply values for the following parameters:
LibraryName: LibraryTest
Author: geewee
Get-ChildItem: /home/geewee/programming/csharp-library-template-test/Expand-Template.ps1:59
Line |
  59 |  …   $snExes = Get-ChildItem -Recurse "${env:ProgramFiles(x86)}\Microsof …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path '/Microsoft SDKs/Windows/' because it does not exist.

Write-Error: sn command not found on PATH and SDK could not be found.

Perhaps a solution here would be simply to disable strong-naming? Microsoft recommends that you don't do it for .net core

AArnott commented 4 years ago

Perhaps a solution here would be simply to disable strong-naming? Microsoft recommends that you don't do it for .net core

I don't think it matters at all on .NET Core either way. To read that they recommend against it might be a bit too strong. Especially in light of their published guidance on docs.microsoft.com that suggest the exact opposite:

You should strong name your open-source .NET libraries. Strong naming an assembly ensures the most people can use it, and strict assembly loading only affects the .NET Framework.

Regardless, this repo creates a library that targets .NET Standard and tests on .NET Framework -- we haven't left everything behind for a brave .NET Core-only world. So ya, we still get benefits from strong name signing.

But I thank you for the bug report. It looks like sn isn't on your path, which is unusual assuming you have the .NET Core SDK installed. Our PR/CI show that this script works on linux/mac but we probably don't go down the 'sn not found' path. So I'll see what I can do to at least improve the error message. We'll probably have to just fail and tell you to get the .NET SDK on your PATH and retry.

GeeWee commented 4 years ago

True, recommends against it is a strong word - but they do say you probably don't need it.

Hm, that is odd in regards to the CI. I've seen suggestions that only Mono includes sn.exe, but that doesn't seem to be the case here.

Odd. Maybe my install is broken somehow.

AArnott commented 4 years ago

Hmm... I have mono and so do the CI machines. Maybe you're right and my script assumes mono is installed...

AArnott commented 4 years ago

Yup: sn comes from mono, as you say:

sn Mono StrongName - version 6.10.0.104

I wonder how to solve this...

AArnott commented 4 years ago

Filed https://github.com/dotnet/sdk/issues/13560 to track adding an sn tool to the .NET Core SDK. In the meantime, I'll improve the error message to say that mono is required.

GeeWee commented 4 years ago

Thanks so much!