Can I use octopus to upgrade .net on the target box

Legacy Uncategorised
1

I would like to make sure my boxes have a minimum version of .net (4.6 for example)

2

Hi Kirk,

Thanks for getting in touch. This might seem like a trite answer (not intended), but if you can do it with PowerShell, you can do it with Octopus Deploy. I would question if it’s the perfect tool for this job - perhaps PowerShell DSC might be a better fit depending on your circumstances.

If you want to do it through Octopus there’s a couple of options I can think of, but all of them will require scripting:

1. Adhoc script using the Script Console

You could write a PowerShell script that downloads the .NET Framework 4.6 installer onto the target machine and executes the installer, and checks the installer log for success/failure. You could then use the script console in Octopus to roll this PowerShell file throughout your fleet, one machine/environment/role at a time.

2. Script Template

You could write script template that does a similar thing, but it firstly checks the registry to see if the version of .NET you desire is installed already (which is harder than it should be). This way you could add the Script Template to the beginning of your deployment process to ensure the expected version of .NET is installed.

NOTE: Neither of these cater for reboots of the target machine, and Octopus doesn’t deal with reboots during a deployment - it will just look like the deployment failed.

Hope that helps!
Mike

3

Thanks. That is very helpful. I was somehow thinking I needed tm make a nuget package with .net. Inside.

If I think of octopus just a script runner, it opens more options.

4

Hi Kirk,

I’m very glad I could help. Please don’t hesitate to reach out if you have any other questions.

Happy Deployments!
Mike

5

Hi guys, have you succeeded in this?

What we have here is a Nuget package with .Net ready + a custom script to start the msi installer.

This all works perfectly on a test project which has a single step.

However if you add any step after .Net deployment whether on the local machine or on the the Octopus server the deployment fails.

The .Net deployment step is marked success, but the step after it (in my case a plain C# Sleep() running on octopus server) is marked as failure.

The sleep step when running alone works fine too.

6

Hi Arnaud,

Thanks for getting in touch! Is the target server rebooting as part of the .NET installation? The reason I ask is because it seems from what you’re saying the Tentacle might be getting shut down which would cause the step to fail, but I’m just guessing.

If you’d like some more help investigating the problem, could you please send through:

If you decide to send this information through I would either recommend scrubbing the information before posting to this thread, or start a new thread, marking it as private, and I’ll follow you up there. :slight_smile:

Hope that helps!
Mike

7

Hi, the raw log already provides some ideas.

(I removed all the intermediate step logs and scrubbed a bit. If you need further information let me know.)

Looks like the tentacle certificate is scrambled by the .Net upgrade?
What is strange here is that a few minutes later the tentacle can be used for other deployments without any changes of the thumbprint.

Here is the .Net install script if still needed:

Write-Host "Checking for .Net 4.6.1 presence"

$value = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' | Select-Object -ExpandProperty 'Release' -ErrorAction Stop


$installNeeded = 1;


if($value -ge 394271) {
  Write-Host ".Net 4.6.1 or higher is already present"
  $installNeeded = 0;
}
elseif($value -ge 393297) {
  Write-Host ".Net 4.6 or higher is already present"
}
elseif($value -ge 379893) {
  Write-Host ".Net 4.5.2 or higher is present"
}
elseif($value -ge 378675) {
  Write-Host ".Net 4.5.1 or higher is present"
}
elseif($value -ge 378389) {
  Write-Host ".Net 4.5 or higher is present"
}
else {
  Write-Host "Found installed version $value"
}

if($installNeeded) {
  Write-Host "Installing .Net 4.6.1"
  $args = ( "/install", "/norestart", "/x86", "/x64", "/q" )
  Start-Process ./NDP461-KB3102436-x86-x64-AllOS-ENU.exe -ArgumentList $args -Wait -Verb "RunAs"
}

ServerTasks-7172.log.txt (10 KB)

8

Hi Arnaud,

Thanks for getting back to me with that info. Wow this is interesting! I can’t think of anything off the top of my head that would cause this kind of behaviour, especially if it self corrects minutes later without any manual intervention.

Could you confirm, is this a listening tentacle or polling tentacle? It will help me understand which endpoint is the “server” and “client” for further research.

At this point I’ll make a few suggestions and see what you think of them.

  1. Consider doing the .NET upgrade as part of a different project. Sometimes customers will use one project for preparing server dependencies and hardening the servers, and then Application projects for deploying their software onto those pre-prepared servers.
  2. Consider running the .NET upgrade asynchronously (start and don’t wait for the result) which might let the subsequent steps complete successfully.

If there is no server reboot occurring, and Tentacle isn’t being restarted, there shouldn’t be any problems - but I can’t guarantee what is happening to the server during the period where the wrong certificate is being used.

Hope that helps!
Mike

9

Hi, these are all listening tentacles and the project at hand is already a machine configuration project. The issue with the failure is that it actually prevents deployment of .Net on the other machines of the role (30+).

Maybe finding a correct configuration to make octopus continue on all target regardless of failure would be the way to go?

But retention policies will never be applied then. Though it may not matter that much in the case at hands.

10

Hi Arnaud,

I thought I’d touch base and see if you’d had any success with this to date?

In Octopus 3.4 we have some features for deploying to “transient” deployment targets. There is a Project configuration setting that will ignore targets if they become unavailable. Maybe this is a reasonable workaround given the obtuse nature of this problem?

I still have no idea why the thumbprint changes temporarily when .NET is upgraded. We are hoping to port Octopus to .NET Core in the near future, meaning Tentacle will be self-contained. Perhaps this kind of problem will be a thing of the past since we won’t depend on assemblies outside of the Tentacle installation?

Hope that helps!
Mike

11

Hi Michael, I planned the upgrade for next week already since multi-tenant support is a feature we’ve been waiting for a lot.

Warm regards,

Arnaud CORNELY
DevOps Manager

12

Hi Arnaud,

Thanks for getting back to me, and I’m glad to hear you’re looking at 3.4. Octopus 3.4 has reached Beta 1, which means the deployment engine itself is complete, we are mainly adding UX improvements from here until RTW… and responding to feedback!

It would be wonderful if you could try 3.4 Beta in your environment, especially multi-tenant deployments, and the idea I suggested for transient environments, and see if that helps.

Don’t hesitate to reach out if you need anything else!
Mike