Why do I receive the warning "The SDK for the 'net-2.0' framework is not available or not configured." when running a delay-sign task in NAnt? - nant

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.

Related

ServerManager.exe -This application could not be started

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

Azure Data Factory self-hosted Integration Runtime auto update issues

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

Is the NuGetToolInstaller task supposed to require .Net 4.7.2 and should using the task add .Net framework 4.7.2 as a demand?

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.

How to upgrade PowerShell version from 2.0 to 3.0?

I write "Add-migration Initial" in Package Manager Console window in Visual Studio 2015 and it says:
EF Core commands do not support PowerShell version 2.0. Please upgrade PowerShell to 3.0 or greater and restart Visual Studio.
I expected to be created a folder Migrations contains the database.
You will have to download and install the Windows Management Framework. Version 3.0 can be found at https://www.microsoft.com/en-us/download/details.aspx?id=34595; version 4.0 can be found at https://www.microsoft.com/en-us/download/details.aspx?id=40855; and version 5.1 can be found at https://www.microsoft.com/en-us/download/details.aspx?id=54616.

on-premises build agent is failing to build solution with projects on .net 4.7.1

We have recently upgraded some projects to .net framework 4.7.1 but our on premise build agent is failed to run the build solution build step. We are using Visual Studio Team Services.
The full error is...
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets (1122, 5)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1122,5): Error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.7" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
The build machine is a windows server 2016 azure VM with Visual Studio 2017, 15.4.4 installed. I manually installed the 4.7.1 .net framework sdk from here: https://learn.microsoft.com/en-us/dotnet/framework/whats-new/index#v471.
I've rebooted and restarted the agent service but still it failed with the above.
Any ideas how to resolve this issue?
The full build solution log file can be found here: Build solution log gist
Thanks,
It turned out the issue was due to not having the 4.7 SDK and 4.7 targeting pack checked under individual components in Visual Studio.