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.

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

Add dependency nuget instructions for PowerShell.Core.Instrumentation resource binary #5396

Merged
merged 9 commits into from Nov 13, 2017
Merged

Conversation

dantraMSFT
Copy link
Contributor

Fix: #4939

This PR adds a dependency on PowerShell.Core.Instrumentation.dll to System.Management.Automation.csproj.

This is a native, resource-only binary containing ETW resource manifest and associated strings.

internals.md documents the steps for creating the nuget package and PowerShell.Core.Instrumentation.nuspec contains the template nuget spec.

@dantraMSFT
Copy link
Contributor Author

NOTE: Merging is dependent on the PowerShell.Core.Instrumentation nuget package being published. I'll update the thread when it is ready.


To successfully decode PowerShell Core ETW events, The manifest and resource binary need to be registered on the system.

To create a new NuGet package for `PowerShell.Core.Instrumentation.dll`, you will need the PowerShell.Core.Instrumentation.nuspec found in the repo under src\PowerShell.Core.Instrumentation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PowerShell.Core.Instrumentation.nuspec should be put in the code block ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

│ └── PowerShell.Core.Instrumentation.dll
```

NOTE: Since these are native binaries used on Windows, they need to be AuthenticodeDual signed, certificate code: 402 before creating the nuget package.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

certificate code: 402

per my discussion with Travis, this code should not be exposed in public. I think only mentioning "need to be AuthenticodeDual signed" should be good enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@@ -16,6 +16,7 @@
<PackageReference Include="System.Security.Permissions" Version="4.4.0" />
<PackageReference Include="System.Text.Encoding.CodePages" Version="4.4.0" />
<PackageReference Include="Microsoft.Management.Infrastructure" Version="1.0.0-alpha*" />
<PackageReference Include="PowerShell.Core.Instrumentation" Version="6.0.0-beta*" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it depended by System.Management.Automation.dll or powershell as a whole? Put it another way, if an application is hosting System.Management.Automation.dll only, does it need the resource dll to work properly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of the code has a direct dependency on the binary. I chose SMA to pull the nuget package since it contains the event raising code. If the dll is not present or the manifest isn't registered, PowerShell will continue to work without issue but the event log and custom consumers won't be able to decode the events.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification. #Close


NOTE: Since these are native binaries used on Windows, they need to be AuthenticodeDual signed, certificate code: 402 before creating the nuget package.

Lastly, run `nuget pack` from teh root of the repo. The following command creates the nuget package from the c:\mypackage directory and places the nuget package in .\src\powershell-win-core. Note that you may need the latest `nuget.exe`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

run nuget pack from teh root of the repo

Type teh.

How about changing it to "Lastly, run the following command from the root of repo."?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed


```powershell
nuget pack .\src\PowerShell.Core.Instrumentation\PowerShell.Core.Instrumentation.nuspec -BasePath c:\mypackage -OutputDirectory .\src\powershell-win-
core
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'core' should not be in a new line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed


### PowerShell.Core.Instrumentation

To successfully decode PowerShell Core ETW events, The manifest and resource binary need to be registered on the system.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

events, The manifest

typo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

<version>6.0.0-RC</version>
```

Next, create the directory structure needed for the contents of the nuget packagestructure. The final directory and file layout is listed below.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

packagestructure

typo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

<authors>Microsoft</authors>
<owners>Microsoft</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>PowerShell Core ETW resource binary</description>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove "Core"? It seems we did this previously.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, we use PowerShell Core all across our .MD files in the repo. (547 times). I figured I'd follow that pattern as well as ensure that there is no confusion between this and Windows PowerShell. That's also the reason I selected the assembly name.

<owners>Microsoft</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>PowerShell Core ETW resource binary</description>
<copyright>Copyright 2017 Microsoft</copyright>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the string (c) Microsoft Corporation. All rights reserved.

Also should we start all XML tags with capitalization?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a survey of all nuspec files in my package cache, and they all use lowercase for the xml elements.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed the copyright text


NOTE: Since these are native binaries used on Windows, they need to be Authenticode Dual signed before creating the nuget package.

Lastly, run the following command from the root of the repo to create the nuget package. The nuget package is placed `.\src\powershell-win-core`. Note that you may need the latest `nuget.exe`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nuget package is placed .\src\powershell-win-core

Maybe "is placed at"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@daxian-dbw daxian-dbw added this to the 6.0.0-RC milestone Nov 10, 2017
@dantraMSFT
Copy link
Contributor Author

FYI: I updated the nuspec to refer to beta.10

@iSazonov
Copy link
Collaborator

What is next release? Beta.10 or RC.1 ?

@SteveL-MSFT
Copy link
Member

@iSazonov @dantraMSFT misspoke, next release is RC

@daxian-dbw
Copy link
Member

daxian-dbw commented Nov 11, 2017

@iSazonov @dantraMSFT was referring to the version of the nuget package PowerShell.Core.Instrumentation, not the next PowerShell release.

After publishing the beta.9 PowerShell.Core.Instrumentation we learnt that resource DLL also needs to be signed, and that's why the beta.10 package was published shortly after.

@daxian-dbw
Copy link
Member

@dantraMSFT There are spelling errors in the .md file. Please see the failed Linux CI.
For file name and file path, you can put them in code block to avoid the spelling check.
For other spelling errors, see https://github.com/PowerShell/PowerShell/blob/master/.github/CONTRIBUTING.md#spellchecking-documentation about how to add them to the .spelling file. When adding a new word to .spelling, please make sure the section that contains the new word is sorted ascendingly (each existing section should have been sorted).

@iSazonov
Copy link
Collaborator

It's confusing. Shouldn't we be using the same version for all packages? It seems .Net Core do so.

@daxian-dbw
Copy link
Member

I agree. That's something we should consider to do. We currently use inconsistent versions for nuget packages that PowerShell depends on, such as pspr.windows, psrp, libmi, MMI and powershell.core.instrument. It would be good if we can unify them before GA.

@dantraMSFT
Copy link
Contributor Author

dantraMSFT commented Nov 12, 2017

libmi is not owned by PowerShell, it is part if omi and it's version is tied to it. Psrp has a build dependency on both libmi and omi so I tied the version to it. It has no dependency on PowerShell and will limely be reved independent of it so I see no reason to version it with PowerShell

@daxian-dbw
Copy link
Member

Good point. So maybe just those nuget packages that are owned by PowerShell itself.

@dantraMSFT Please fix the spelling errors in Travis-CI build. See my comment #5396 (comment) for more info. We cannot merge the PR with the failed CI.

@dantraMSFT
Copy link
Contributor Author

@daxian-dbw, I fixed spelling issues; updated .spelling with new entries (authenticode and PowerShell.Core.Instrumentation)

@adityapatwardhan
Copy link
Member

@dantraMSFT Just to confirm, the nuget package has been published right?

@dantraMSFT
Copy link
Contributor Author

@adityapatwardhan: Yes, the nuget package has been published.

@adityapatwardhan adityapatwardhan merged commit d5a974f into PowerShell:master Nov 13, 2017
@dantraMSFT dantraMSFT deleted the dantra/issue4939 branch November 13, 2017 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants