I was able to remedy this by declaring:

  <configuration>
    <startup>
      <supportedRuntime version="v4.0" />
    </startup>
  </configuration>

in a .exe.config file -- however, the docs say this shouldn't be necessary with the dotnet-4 specific builds. I am also not really happy to see the binary changed out from under itself at runtime, that is some hostile behavior at first glance!

Do you have the download feature enabled (self-update)?

I am suffering this issue on 2.4.0. I was following this this guide. Just started looking at it.

Even though I was running the -net4 version (I have .net 4.5 installed), it seems to replace it with a version that installs < .net 4.0 and thus seems to break because it wants to install .net 3.5!

I'll let you know if I find a way round it.

Found the issue. The link above names the .config file .conf, and thus its not read and replace by a binary for .net < 4.0! Then the binary wants to install .net 3.5 when 4.5 is already installed!

Also a oddity. I am using version 2.4.0. When I start the service, it renames the binary to .bak and replaces it with a 2.3.0 binary. Seems odd it down graded it? When I say version, I used the version arg to check the version.

To be clarified, .NET 4+ versions of WinSW will not request to install .NET 3.5. And WinSW didn't have self-updating functions. Even if something is configured to update it, the latest release version is 2.4.0 on Jenkins releases and 2.6.2 on Github releases. Why did it download the 2.3.0 version?

You missed the point about the .exe.config being called .exe.conf and being ignored:

<configuration>
  <startup>
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

So that is why the .net < 4.0 binary was downloaded.
I am using the jenkins releases (2.4.0 latest). Not familiar with the auto download process of the binary; let me read the docs to see if its mentioned.

You missed the point about the .exe.config being called .exe.conf and being ignored:

The .NET 4 binary doesn't need the .exe.config file to specify the runtime version.

https://github.com/kohsuke/winsw/blob/master/doc/installation.md#making-winsw-1x-compatible-with-net-runtime-40

This is windows server 2012 r2 with .net 4.5 installed. Its a long story why windows is an old release; lets say its a big platform (lots of servers), a big company, the business revolves around this platform and its not my call to upgrade it (although I have mentioned it in the past). I am not sure why it has .net 4.5 rather than the default (3.5?), other than we need to keep it up to date with security patching, as well as making it compatible with modern software, etc.

I think https://github.com/kohsuke/winsw/blob/master/doc/exeConfigFile.md could do with some docs? I had a quick look through and apart from the download section for the main config file, am not sure why it auto updates. I looked through the logging and could not see anything relating to the auto upgrade.To be honest the downgrade to 2.3.0 is not an issue as it works fine, but I wonder if it might be a problem in the future? Would be nice to turn off the auto upgrade feature?

Thanks for taking the time to report this issue. I've found the problem.

WinSW self-updating was implemented as a "feature" as a part of JENKINS-19055.

The 2.3.0 version is defined here: https://github.com/jenkinsci/jenkins/blob/3ebb9e3592d648bb0408634b8f92ec3b6fb0c54e/core/pom.xml#L796

I don't see it in the links you provide. I see the references to updating slave.jar using download from, but not the actual auto update of WinSW itself.

Also how do you turn the auto update off?

The auto update is implemented in Windows Agent Installer module.

See Disabling Automatic upgrade for how to disable it.

Holy moly, did not know about those docs. It would have been easier to follow the auto install than doing it manually.

Thanks for all the help.

I tried downgrading to 2.3.0, but the jenkins master still downloads its own version of winsw (2.3.0) and replaces your version (yours will be renamed to .bck).

For the benefit of others: If you are running Oracle jdk/jre on your client, and it has java web start (javaws), open a browser to your jenkins master from the client, go to the windows agent node on the gui. Click the Launch button and open or download the .jnlp file.Then open the file with java web start and run it. When the agent is up and running, click on File and then Install as a service. Then open services (run services.msc) and check its running. No need to setup winsw manually!

I tried downgrading to 2.3.0, but the jenkins master still downloads its own version of winsw (2.3.0) and replaces your version (yours will be renamed to .bck).

IIUC it downloaded the .NET 2 version and replaces the .NET 4 one. The installer module currently determine versions by MD5 checksum of the binary rather than version strings.

The installer should be fixed to:

• Check version by parsing winsw verison or inspecting the PE headers.
• Do not downgrade.

Closing as answered in #399 (comment).