I am building out a brand new 2016 CI system, and I ran into a problem with Octopack’s nuget 3.6.3. It fails to run at all. The error I get is Error: “This application could not be started” just attempting to launch the package. The details about the error indicate the following:
"The app is not configured in a way that makes it possible to determine the appropriate version of the .NET Framework runtime. The corresponding shim code is SHIM_NOVERSION_FOUND.
You can’t fix the configuration problem yourself. Contact the app vendor to resolve the issue."
This is a stock Windows 2016 server AMI from amazon with the defaults (4.6, 4.7). I installed .NET 3.5/4.5.x as well to no available. According to the Octopack package nuget was build specifically for Octo, what is required to make it work on a bare metal 2016 server.
I found the fork of NuGet for Octo, given that I use RunOctoPack command switches as a part of the build, is there any way to get the version of nuget listed below into a version of OctoPack? This version works properly on the server in question.
I did some research into your question this afternoon and did a little double-checking of the Octopack 3.6.3 package - according to what I found, Nuget.exe is marked for dependency on TargetFramework(".NETFramework,Version=v4.5", FrameworkDisplayName = “.NET Framework 4.5”) though the IL disassembler I’m using suggested runtime version v4.0.30319.
Given the information you provided, I’d suggest installing that V4 runtime ought to get you past the error message, and get you up and running.
I have every framework installed all the way back to 3.5 and the custom nuget.exe inside OctoPack flat will not run. I am relying on OctoPackNuGetExePath to point to a stock versin of NuGet which we are using 4.7.1. What am I losing out on by not using the one bundled in OctoPack?
The forked version that comes bundled is there due to a behaviour in the stock nuget that strips leading zeroes from versions, which can cause a mismatch with Octopus. You’ll only be impacted if your versioning scheme runs into this quirk, so chances are you’ll be fine.
I am a little confused about the Framework thing though. I’ll raise it with the team and do some verification work
Thank you for the clarification, based on that I think we will be fine. It should be pretty easy to reproduce I just launched a Windows Server 2016 base AMI in AWS (latest), installed the latest 2017 MS Build tools on it and selected all framework options in the process, did the usual server reboot just to be sure. End result was the shim error no matter what I tried to do.