search

OctopusDeploy / StepsFeedback

| Public |
0 stars 0 forks source link

Migrating from ScriptCS to dotnet-script (and deprecating Mono support) #9

Open IsaacCalligeros95 opened 2 years ago

IsaacCalligeros95 commented 2 years ago

Please add a comment to this issue with your feedback regarding the Migration from ScriptCS to deploy-script. The details blog post can be found here.

We have a few general areas that we are actively seeking feedback on, listed below. But any feedback is welcome.

Edit: This change is intended for June 30th and will be released in the 2023.3 stream.

twenzel commented 2 years ago

Will the removal of C# scripts from Linux SSH targets or Windows versions older than 2012R2 affect you? No

Do the newer language features, easier NuGet package reference, and added reliability in removing Mono justify these changes? YES! New language features and direct referencing NuGet packages will be awesome and would make the deployment scripting much easier!

Daniel-Svensson commented 2 years ago

You might already have fixed this but would F# also make the move from the old fsc.exe to dotnet fsi ? Would love that

Will there be a simple setting for choosing dotnet version to run? For example one might have dotnet 6/7 on the build agents and want to use that instead if whatever version calamari comes with.

Desarc commented 2 years ago

Will the removal of C# scripts from Linux SSH targets or Windows versions older than 2012R2 affect you? No

Do the newer language features, easier NuGet package reference, and added reliability in removing Mono justify these changes? Yes. We also run a lot of C# scripts in other contexts outside Octopus Deploy, and these have all been updated to run on dotnet-script already. Octopus Deploy/Calamari is currently the only thing that forces us to still use ScriptCS. Looking forward to this change!

IsaacCalligeros95 commented 2 years ago

Thanks, everyone for your feedback, It's appreciated and helps us push this change forward!

@Daniel-Svensson

You might already have fixed this but would F# also make the move from the old fsc.exe to dotnet fsi ? Would love that

We haven't upgraded F# scripting yet but following an update to dotnet-script it makes a lot of sense to upgrade to dotnet fsi as well 🙂

Will there be a simple setting for choosing dotnet version to run? For example one might have dotnet 6/7 on the build agents and want to use that instead if whatever version calamari comes with.

We haven't considered that yet, dotnet script ships with core3.1, net5.0 and net6.0 currently. Since dotnet tools can run independently of the machine's runtime this makes a lot of sense. There may however be edge cases where scripts are required to run on the same version as the target machine. I'll investigate this and discuss with the team. If there's any progress or decision reached on F# I'll make sure to reach out.

Overall these are changes that we'd like to be able to just ship but due to deprecating inbuilt .Net Framework support, we're trying to give this time to spread through the community and allow people to update any scripts that could be affected. The more feedback we receive here, the more confident we are that people have seen the message and have either upgraded their C# scripts where required or won't be affected. We appreciate the positive feedback and will keep you updated on when this is likely to ship.

officeSpacePirate commented 1 year ago

@IsaacCalligeros95 Looks like this doesn't have a ton of traction since it was opened, but ScriptCS has officially dropped support since this time: https://github.com/scriptcs/scriptcs/issues/1323

Not sure whether that raises the priority of switching to dotnet-script. If it's not already apparent, I am commenting here because I would like to see these changes (I work for a company with a large Octopus contract). We currently have a myriad of custom Step Templates written in Powershell and the overhead would be reduced moving C#. Switching with ScriptCS has not made sense for several years now because of their limitations.

IsaacCalligeros95 commented 1 year ago

@IsaacCalligeros95 Looks like this doesn't have a ton of traction since it was opened, but ScriptCS has officially dropped support since this time: scriptcs/scriptcs#1323

Not sure whether that raises the priority of switching to dotnet-script. If it's not already apparent, I am commenting here because I would like to see these changes (I work for a company with a large Octopus contract). We currently have a myriad of custom Step Templates written in Powershell and the overhead would be reduced moving C#. Switching with ScriptCS has not made sense for several years now because of their limitations.

Hey @officeSpacePirate Sorry I missed this the other week. The changes for this migration are complete and we've committed to going ahead with this change. We'll merge updates on June 30th targeting 2023.3 which includes cloud customers. Thanks for adding your voice to support this, it's been a process getting confirmation on customers that will be impacted and working through potential issues. I appreciate everyone's patience on this and will update this thread with the version that dotnet-script is available in.

Please let me know if there are any other tooling issues you're experiencing. Internally we're working on improving our processes for deprecations and this was one of the first things we've looked at so any feedback on the process is appreciated.

wfroese commented 1 year ago

Subscribing here, and adding my two cents that I'm looking forward to this feature. Just looking for it in the self-hosted release stream at this point.

JSommersKLH commented 3 months ago

The migration instructions are too vague, and applying the required changes has caused all of my c# scripts to fail stating: error CS0103: The name 'OctopusParameters' does not exist in the current context

brendangooden commented 4 days ago

Looking forward to this feature in the self-hosted release. Been waiting for the async/await and custom using references for a while.