New DSC resource to install tools from dotnet globally #63

Gijsreyn · 2024-10-07T07:28:13Z

I have signed the Contributor License Agreement.
This pull request is related to an issue.

This pull request introduces a new DSC resource. It allows users to install .NET tools globally.

Gijsreyn · 2024-10-07T07:30:32Z

@denelon Hi Demitrius, I had gone through the CONTRIBUTING.md, but I was unsure if I had to commit the spec-template file with this PR. Do you want me to include it?

denelon · 2024-10-07T15:50:22Z

Yes please. Any additional documentation will be helpful as users become informed about the new resource.

denelon · 2024-10-07T15:56:18Z

It might also be interesting to get you connected to some of the dotnet folks to discuss making dotnet.exe DSC v3 capable. I saw you're writing an e-book on DSC v3 in your GitHub profile.

denelon · 2024-10-07T15:58:24Z

We have been discussing a DSC Resource for dotnet recently. I would have thought about using a module name like "Microsoft.dotnet.Dsc" or something like that. I just don't have enough domain knowledge on dotnet to make the best recommendation.

Gijsreyn · 2024-10-07T16:09:31Z

Yes please. Any additional documentation will be helpful as users become informed about the new resource.

Will do when I have some time. In the meantime, if you have any suggestions or best practices how you want the docs to look like, just give me a headsup :)

Gijsreyn · 2024-10-07T16:11:13Z

It might also be interesting to get you connected to some of the dotnet folks to discuss making dotnet.exe DSC v3 capable. I saw you're writing an e-book on DSC v3 in your GitHub profile.

Would love that Demitrius. Great challenge to look at. Indeed I am. Currently storing the content from preview.10 and asked Gael to have a review/foreword. Then probably when dsc gets GA, I'll put it fully live.

Gijsreyn · 2024-10-07T16:12:07Z

We have been discussing a DSC Resource for dotnet recently. I would have thought about using a module name like "Microsoft.dotnet.Dsc" or something like that. I just don't have enough domain knowledge on dotnet to make the best recommendation.

I would recon a naming change. It was just as first thought that popped up.

denelon · 2024-10-07T16:16:54Z

Related to:

DSC resource to install tools from dotnet #65

MichaelSimons · 2024-10-07T19:50:04Z

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psd1

+    RootModule = 'Microsoft.NET.SDK.ToolInstaller.psm1'
+    ModuleVersion = '0.1.0'
+    GUID = '2e883e78-1d91-4d08-9fc1-2a968e31009d'
+    Author = 'Microsoft Corporation'


@denelon - Is there an ownership concept with DSCs similar to Winget packages? How do you ensure the validity of the author and that they have sole ownership?

Since this is an OSS repository, we'd consider PRs from the community, but since this is a Microsoft "package" the resource would require our approval to make sure we're good with the implementation. Anything published to the PowerShell gallery from here would need that validation before we would sign and publish the module.

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1

marcpopMSFT · 2024-10-07T23:00:58Z

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1

+    return $dotNetPath
+}
+
+# TODO: when https://github.com/dotnet/sdk/pull/37394 is documented and version is released with option simple use --format=JSON


The linked PR is fixed in 9 it looks like. Were you waiting for 9 to be the default to replace the below code?

You are right, I forgot I couldn't install the latest preview from the official website. Everytime when I tried downloading, it gives me 0 bytes. When I used winget install Microsoft.DotNet.SDK.Preview, it did. I guess it installs from a different location.

Eventually, I guess we can move the logic to this:

But we should also be able to support older versions of the SDK?

marcpopMSFT · 2024-10-07T23:02:06Z

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1

+    process
+    {
+        $installArgument = Get-DotNetToolArguments @PSBoundParameters
+        $arguments = "tool install $installArgument --global --ignore-failed-sources"


are all of the tools you're installing supported on the current runtimes that are installed? if not, there may be issues with running those tools.

I agree with your statement here, however I do think users themselves should be aware what they should install. I know the architecture option is also available to be specified. It can be added later I would say. Let me know your thoughts.

marcpopMSFT · 2024-10-07T23:03:48Z

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1

+    }
+
+    Set() {
+        # TODO: validate for upgrade/update scenarios


what is the update model for this?

Let's imagine the following scenario. The user has already installed PowerShell version 7.4.4. The user now wants version 7.4.5. The user leaves empty the version property. When the user runs the configuration, it needs to check if 7.4.4 is installed and if so, update it with dotnet tool update. @ryfu-msft Would you agree with such logic, or should we add a boolean parameter to upgrade?

Agreed. If a package has a version that does not match the desired version, then this DSC resource should handle updating the package to match the desired state.

marcpopMSFT · 2024-10-07T23:07:03Z

tests/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.Tests.ps1

+     It 'Sets desired package with prerelease version' -Skip:(!$IsWindows) {
+        $parameters = @{
+            PackageId = 'PowerShell'
+            Version = '7.2.0-preview.5'


why this version of powershell?

If I'm not mistaken, the logic of the CLI to install packages is as followed:

Whenever a preview version is higher than the official version, you require the --prerelease parameter to be added without version

When the official version is higher than a preview version, you use the --version parameter to indicate you want to install a prerelease version that is older. Because you want to test for this scenario, I have included an older version of PowerShell. See list:

Gijsreyn · 2024-10-08T14:06:14Z

@denelon In the latest commit, I have added the option for toolsPath. This allows users to choose a directory to install tools towards.

However, the latest pull request for Microsoft.VSCode.DSC, broke the participation on the export because we removed the static method. I asked Mikey for feedback on enabling export for class-based resources directly from PSDesiredStateConfiguration.

I have tried to incorporate as much of what Mikey sketched out in this change. It probably requires updating the Microsoft.VSCode.DSC also if this is the way forward.

P.S. After thinking about it, DotNetDsc would to it for me.

denelon · 2024-10-08T15:23:33Z

@denelon In the latest commit, I have added the option for toolsPath. This allows users to choose a directory to install tools towards.

However, the latest pull request for Microsoft.VSCode.DSC, broke the participation on the export because we removed the static method. I asked Mikey for feedback on enabling export for class-based resources directly from PSDesiredStateConfiguration.

I have tried to incorporate as much of what Mikey sketched out in this change. It probably requires updating the Microsoft.VSCode.DSC also if this is the way forward.

P.S. After thinking about it, DotNetDsc would to it for me.

I'd suggest trying with the experimental WinGet feature something like:

winget configure export --Resource Microsoft.dotnet.Dsc -o dotnet.winget to see if the settings get exported.

I know this is brutal with class-based v2 modules, but it gives us another working example and helps pave the way for DSC v3. We're investing into improvements for the export feature to capture all installed packages, Windows Settings, and any DSC v3 resources (soon to be identified in WinGet package manifests).

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psd1

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1

ryfu-msft · 2024-10-08T18:32:09Z

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1

+    }
+
+    Set() {
+        # TODO: validate for upgrade/update scenarios


Agreed. If a package has a version that does not match the desired version, then this DSC resource should handle updating the package to match the desired state.

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1

pipelines/azure-pipelines.yml

Gijsreyn · 2024-10-11T04:40:25Z

@ryfu-msft Ryan, sorry for the many commits. I had to re-name the module and figure things out with Semantic Versioning. I have tried to prepare the test to run on the ADO agents. Inside the .psd1 file, the LicenseUri and ProjectUri are included. This is more convenient for people to be redirected when they want to do changes. You mind giving it another look and run the pipelines?

Cheers and have a good weekend already.

ryfu-msft · 2024-10-15T16:45:41Z

/azp run

azure-pipelines · 2024-10-15T16:45:52Z

Azure Pipelines successfully started running 1 pipeline(s).

resources/Microsoft.DotNet.Dsc/Microsoft.DotNet.Dsc.psm1

ryfu-msft · 2024-10-16T18:11:24Z

resources/Microsoft.DotNet.Dsc/Microsoft.DotNet.Dsc.psm1

+                else 
+                {
+                    # Don't want to downgrade scenarios
+                    Throw "The package version cannot be less than the installed version. Please provide a version greater than or equal to the installed version."
+                }


We shouldn't be throwing on a Get() call. I also believe that we should still support downgrade scenarios even if this is not a common scenario. DSC should be able to set any desired state even if that involves downgrading.

Please check once again. The logic is a bit different. Check out the GitHub issue linked at the function. Not all SDKs have the downgrade option ;)

resources/Microsoft.DotNet.Dsc/Microsoft.DotNet.Dsc.psm1

…inget-dsc into net-sdk-toolinstaller

Gijsreyn · 2024-10-21T03:44:26Z

@denelon I have also sketch out a proposed solution in the sdk repository. I can imagine that it hasn't the highest priority, but if one operation already is exposed, this becoms obsolete.

If there is anyone whiling to participate, my C# knowledge is rusty. A first set up would greatly assist me.

resources/Microsoft.DotNet.Dsc/Microsoft.DotNet.Dsc.psm1

ryfu-msft · 2024-10-21T16:11:25Z

/azp run

azure-pipelines · 2024-10-21T16:11:36Z

Azure Pipelines successfully started running 1 pipeline(s).

ryfu-msft · 2024-10-22T01:17:21Z

/azp run

azure-pipelines · 2024-10-22T01:17:30Z

Azure Pipelines successfully started running 1 pipeline(s).

ryfu-msft

Look great! Will work on getting this published to the gallery. Thank you so much for all your hard work on this! 😄

Gijsreyn · 2024-10-22T07:58:47Z

And thanks for all the feedback! Please let me know when you get it published

denelon · 2024-10-22T15:24:21Z

@Gijsreyn,
It's published: https://www.powershellgallery.com/packages/Microsoft.DotNet.Dsc/0.1.1-alpha

Gijsreyn · 2024-10-22T17:40:00Z

@denelon Thanks for letting me know. I'll try to put out some docs tomorrow and spend some love in some upcoming blogs I'm writing. Curious to your thoughts. Cheers.

denelon · 2024-10-22T21:20:12Z

@ryfu-msft and I were chatting about the best place to put docs here, and a sample over at https://aka.ms/dsc.yaml inside the Dev Home repository. We could also consider centralizing examples here now that this repository is open to the public. That would allow me to change the redirect to this repository.

New module for installing .NET SDK global tools

3997302

TODO task

f57f754

denelon requested a review from ryfu-msft October 7, 2024 15:56

MichaelSimons reviewed Oct 7, 2024

View reviewed changes

marcpopMSFT reviewed Oct 7, 2024

View reviewed changes

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1 Outdated Show resolved Hide resolved

marcpopMSFT reviewed Oct 7, 2024

View reviewed changes

resources/Microsoft.NET.SDK.ToolInstaller/Microsoft.NET.SDK.ToolInstaller.psm1 Outdated Show resolved Hide resolved

marcpopMSFT reviewed Oct 7, 2024

View reviewed changes

Adding toolspath option

f35e39d

ryfu-msft suggested changes Oct 8, 2024

View reviewed changes

Gijsreyn added 4 commits October 10, 2024 10:51

Rewrite Microsoft.Dotnet.Dsc

a4e0642

Remove minor comments

0826de3

Adding uninstall scenarios and SemVer comparison

336fbc0

Fix unit test to run on ADO agent

23d2c67

Merge branch 'main' into net-sdk-toolinstaller

6339295

ryfu-msft suggested changes Oct 16, 2024

View reviewed changes

Gijsreyn added 2 commits October 17, 2024 09:28

Adding downgrade option

bbe9ef0

Merge branch 'net-sdk-toolinstaller' of https://github.com/Gijsreyn/w…

0d18750

…inget-dsc into net-sdk-toolinstaller

Gijsreyn mentioned this pull request Oct 21, 2024

Participate dotnet tool as first-class resource for DSC operations dotnet/sdk#44325

Open

ryfu-msft suggested changes Oct 21, 2024

View reviewed changes

resources/Microsoft.DotNet.Dsc/Microsoft.DotNet.Dsc.psm1 Outdated Show resolved Hide resolved

resources/Microsoft.DotNet.Dsc/Microsoft.DotNet.Dsc.psm1 Outdated Show resolved Hide resolved

ReInstall helper added

929dcf0

ryfu-msft approved these changes Oct 22, 2024

View reviewed changes

ryfu-msft merged commit 39ffbb6 into microsoft:main Oct 22, 2024
4 checks passed

denelon mentioned this pull request Oct 22, 2024

DSC resource to install tools from dotnet #65

Open

New DSC resource to install tools from dotnet globally #63

New DSC resource to install tools from dotnet globally #63

Uh oh!

Conversation

Gijsreyn commented Oct 7, 2024

Uh oh!

Gijsreyn commented Oct 7, 2024

Uh oh!

denelon commented Oct 7, 2024

Uh oh!

denelon commented Oct 7, 2024

Uh oh!

denelon commented Oct 7, 2024

Uh oh!

Gijsreyn commented Oct 7, 2024

Uh oh!

Gijsreyn commented Oct 7, 2024

Uh oh!

Gijsreyn commented Oct 7, 2024

Uh oh!

denelon commented Oct 7, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gijsreyn commented Oct 8, 2024

Uh oh!

denelon commented Oct 8, 2024

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Gijsreyn commented Oct 11, 2024

Uh oh!

ryfu-msft commented Oct 15, 2024

Uh oh!

azure-pipelines bot commented Oct 15, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Gijsreyn commented Oct 21, 2024

Uh oh!