We have a build VM that's on an older version of Windows 10 because we have a 3rd party component that can't be installed on newer versions. That version of Windows 10 doesn't support installing .Net Framework 4.7.2, and this appears to be required for the NuGetToolInstaller to work. Is there anyway to get NuGet working in a build that will work with all Windows 10 builds (or even Windows 7)?
I can force it to only choose to build on a VM with a later build of Windows 10 by manually adding a demand for .Net Framework 4.7.2, but shouldn't the NuGetToolInstaller task already include that demand (in the same way that the Visual Studio Build task does)?
and this appears to be required for the NuGetToolInstaller to work.
Check this json file, it shows all the supported versions in task NuGettoolinstaller, we can see that it can be installed from version 2.8.6, I try to install it with the version 2.8.6 and it works, check the pic below.
According to the description, it seems that you are using self-hosted agent, it will check the configuration of the local machine. If you have another version installed on your local agent machine, we can also use the NuGet version.
Related
I have problem on Windows Server 2019, all application which use .Net cannot be started. I have 4.8 version with all windows update. But I get this error. I tried reinstall, use fix tool for .NetFramework but i cannot fix .NetFramework
enter image description here
We just found this solution. (https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/windows-server-2019-and-net-4-8/m-p/2660319)
I ran into this issue after the Windows Update, Cumulative Update for .NET Framework (KB5006765), was installed on a Windows Server 2019 that also had Azure AD Connect installed. Apparently, a bunch of .NET registry items where deleted. Server Manager and any software built on .NET was not working...throwing this error:
This application requires one of the following versions of the .NET Framework: v4.0.30319
Do you want to install this .NET Framework version now?
DSIM and SFC repairs did not work, nor did rolling back the Windows Update.
Found some insight here:
https://www.bleepingcomputer.com/forums/t/758800/net-48-kills-server-2019/
Ended up having to import these registry items from a working system:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.1,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.2,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.3]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.3,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5.3]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.6]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.6.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.6.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.7]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.7.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.7.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\Default]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"AspNetEnforceViewStateMac"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.1,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.2,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.3]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.0.3,Profile=Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5.3]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.6]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.6.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.6.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.7]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.7.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.7.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\Client]
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SKUs\Default
I have some problem with self-hosted Integration Runtime in Azure Data Factory V2.
I have a few VMs running 4.X.X IR software. Some of them had auto update enabled in DFv2
There was an update from 4.X.X to 5.X. After this, IR is unavailable from DFv2.
Looks like the IR services running on the VMs are pointing to a wrong execute path - using still 4.0. I can fix it manually with sc config or reinstall IR, but after reboot it doesn't work again.
Is that a bug? Can I somehow fix it without removing the VMs?
Update:
What I did - I went to Data Factory V2 Integration Runtimes and picked my self-hosted IR, went to Auto update and enabled it. My Virtual Machine hosting this IR was running an older IR software (4.X.X). There was an update to 5.X.X. Everything was working fine until I rebooted the VM. After this from Data Factory V2 Integration Runtimes I was seeing an error saying that my self-hosted IR is unavailable. I logged into the hosting VM and it turned out that IR software cannot start its service dmgsvc.exe. When you go to services.msc and check the Integration Runtime service pointing to the dmgsvc.exe, the path will be incorrect. What was wrong there? It was a catalog 4.0 instead of 5.0. IR software cannot start up correctly because of that and the error is Error 2: System cannot find the file specified. So what I did? I manually fixed it and it was working. But after the first reboot of the VM it was again pointing to the 4.0 catalog. I reinstalled the software and the effect was the same.
For the upgrade to version 5.x of the Azure Data Factory self-hosted integration runtime, we require .NET Framework Runtime 4.7.2 or later. On the download page, you'll find download links for the latest 4.x version and the latest two 5.x versions.
If automatic update is on and you've already upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime will be automatically upgraded to the latest 5.x version.
If automatic update is on and you haven't upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime won't be automatically upgraded to the latest 5.x version.
The self-hosted integration runtime will stay in the current 4.x
version. You can see a warning for a .NET Framework Runtime upgrade
in the portal and the self-hosted integration runtime client.
Refer: Troubleshoot self-hosted integration runtime
I just updated my TeamCity server and I am suddenly getting this error message on my build agent.
I made a copy of the old installation, and the buildAgent.properties are the exact same. The Plugin folder for powershell exists aswell.
Does anyone have an idea on how to fix this?
I had the same problem when moved the build agent from windows to linux, and found the solution here.
In short:
Make sure powershell is installed on the server where the build agent is running.
You can set Platform and (Since TeamCity 2017.1) Edition properties at the PowerShell build step Edit page.
Edition: on windows Desktop, on linux Core
Platform: could be x64 or x86 based on installed version
If you set these properties correctly, it should meet the requirements, and you can use the build agent as before.
I recently upgraded my deployment build configuration to use Powershell V3.0 (from 2.0). I installed the necessary Microsoft package on my agent and the agent $PSVersionTable shows {1.0, 2.0, 3.0} locally.
After manually queuing the build, the queue displays:
However, when clicking 'More details >>', my agent is listed as compatible:
Why is the compatible build agent not building?
I've also followed the instructions to refresh the build agent by deleting some of the folders as indicated in this post.
Teamcity 8.0.2
Update
Installing Powershell v3.0 on the incompatible agent allows the system to build the configuration just fine, however, forcibly choosing my agent still won't build.
I'm using NAnt 0.85 as a build script. Part of the script is to complete the signing process of delay-signed assemblies using the delay-sign task.
When the script is executed on the build server, it runs without any problems.
When I run the same script on my local development machine, I get the warning:
The SDK for the 'net-2.0' framework is not available or not configured.
at NAnt.Core.Tasks.ExternalProgramBase.DetermineFilePath()
at NAnt.Core.Tasks.ExternalProgramBase.get_ProgramFileName()
at NAnt.Core.Tasks.ExternalProgramBase.PrepareProcess(Process process)
at NAnt.Core.Tasks.ExternalProgramBase.StartProcess()
at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask()
at NAnt.DotNet.Tasks.DelaySignTask.ExecuteTask()
at NAnt.Core.Task.Execute()
at NAnt.Core.Target.Execute()
at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies)
at NAnt.Core.Tasks.CallTask.ExecuteTask()
at NAnt.Core.Task.Execute()
at NAnt.Core.Target.Execute()
at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies)
at NAnt.Core.Project.Execute()
at NAnt.Core.Project.Run()
I'm pretty sure I've got the SDK installed with Visual Studio 2008/2010.
Why do I receive this error and what can I do to diagnose the problem further?
The error is because I didn't have the .NET 2.0 SDK. I assumed SDKs were installed with Visual Studio, but apparently only the current version is. For 2008, that's .NET 3.5 SDK, not 2.0 and previous versions aren't provided.
Downloading and installing the 2.0 SDK from Microsoft resolved the issue.
For me, the fix was to update nant to 0.92. Nothing I did with the .NET 2.0 SDKs worked.
I also ran into this problem. I ensured that the 2.0 SDK was installed, and I upgraded to the latest version of NAnt, but that did not fix it. I verified the registry entries and even hard-coded the location of the SDK in the config -all to no avail.
What finally worked for me was to install the 32-bit version of the .NET 2.0 SDK on my 64-bit machine.