I'm using Visual Studio 2019 and just created a new .NET Core 3.1 web api project.
I noticed, that an option "use remote machine" is missing from the debug tab of project's properties.
However, when I open my old project, created in older versions of VS using .NET Core 2 (and then migrated to 3.1) - the option is present.
I've only recently started needing it and this inconsistency is strange to me.
This ticket on Microsoft website https://developercommunity.visualstudio.com/t/use-remote-machine-option-in-debug-settings-is-not/757921 suggests that it should be fixed in the latest version of VS, but I use the latest version and the problem still remains.
I figured it out, was my mistake. I needed to explicitly set launch option to executable. Then it becomes available. I should close the question.
I am trying to run the Xamarin.Android app from Microsoft Azure Guides.
According to the guide I am supposed to right-click on the Service project and Rebuild, after that on clicking Publish I get the Publish Target window but there is no target of Azure App Service. I only get Target of Azure Web Apps
Updating the Azure SDK was the solution for me. The following page has all the downloads, select your visual studio version to the left
https://azure.microsoft.com/en-us/downloads/
VS2015 Direct link: https://go.microsoft.com/fwlink/?LinkId=518003&clcid=0x409
I'm assuming the project to which you refer is the "QuickStart" server-side project that is downloaded and named yoursite-Runtime.zip. When unpacked, you get a folder yoursite_AppService and yoursite.sln in the file.
When you right-click and select Publish, you should see the following picture as the pop-up:
If this is not the case, then there is something at issue with your install of Visual Studio 2015 - perhaps an additional plugin or an older version of Azure SDK? Try updating the Azure SDK as a starting point.
I've just installed the April 2015 release of the Azure SDK. It is version 2.6 and previously I was on 2.5. Now one of my projects will not load. It is the shared project in a Windows Universal application.
When I right-click the project and choose 'reload' I get the pop-up error
The method or operation is not implemented
The output window gives more detail:
Things.Shared.shproj : error : The composition produced a single
composition error. The root cause is provided below. Review the
CompositionException.Errors property for more detailed information.
1) No exports were found that match the constraint:
ContractName Microsoft.VisualStudio.ProjectSystem.References.IBuildDependencyProjectReferencesService
RequiredTypeIdentity Microsoft.VisualStudio.ProjectSystem.References.IBuildDependencyProjectReferencesService
Resulting in: Cannot set import
'Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService.ProjectReferencesService
(ContractName="Microsoft.VisualStudio.ProjectSystem.References.IBuildDependencyProjectReferencesService")'
on part
'Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService'.
Element:
Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService.ProjectReferencesService
(ContractName="Microsoft.VisualStudio.ProjectSystem.References.IBuildDependencyProjectReferencesService")
--> Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService
Resulting in: Cannot get export
'Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService.WireUp
(ContractName="Microsoft.VisualStudio.ProjectSystem.ConfiguredProject.AutoLoad")'
from part
'Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService'.
Element:
Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService.WireUp
(ContractName="Microsoft.VisualStudio.ProjectSystem.ConfiguredProject.AutoLoad")
--> Microsoft.VisualStudio.Azure.Deployment.ProjectReferenceMaintenanceService
The other parts to the Windows Universal app (the Windows 8.1 project and the Windows Phone 8.1 project) have two Azure NuGet packages installed: Windows Azure Mobile Services 1.3.2 and Windows Azure Storage 4.3.0. (N.B. Those two projects load without issue.)
This is not a show stopper for me since uninstalling the Azure SDK 2.6 removes the load failure. To uninstall I go via the Control Panel to 'uninstall or change a program' and then uninstall Microsoft Azure Tools for Microsoft Visual Studio 2013 - v2.6
I would like to know how to fix this without uninstalling the Azure SDK 4.6.
Over on the Azure Mobile Services forum Chuck Weininger has posted the following answer:
The [fixed] build of Azure SDK 2.6 is now available, but it may not have
propagated to all download servers yet.
You can run the Web Platform Installer and if you don’t have the new
build installed, it should allow you to install 2.6 again. But it
might not if you are accessing a download server that doesn’t have the
new bits yet. If WebPI doesn't allow you to install 2.6 again, then
wait a few hours and try again.
The build number for the version with the fixes is build
2.6.30508.1601. You can identify the build of the SDK from Control Panel -> Programs and Features -> Microsoft Azure Tools for Microsoft
Visual Studio 2013 – v 2.6. The Version column will display the build
number
I have followed Chuck's instructions and have the new build and the shared project now loads without issue.
We have been able to reproduce the issue, but don't have a workaround at this time. If you want to use the Universal App projects with VS 2013, you will have to uninstall Azure SDK for VS 2.6. The issue does not happen on VS 2015 RC if you would like to give that a try. We hope to have news soon about how we can get a fix for this issue on VS 2013.
Chuck Weininger, Dev Lead, Microsoft
https://social.msdn.microsoft.com/Forums/en-US/e8123821-dcb1-477f-a746-f6f016a724ea/cannot-load-shared-project-in-windows-universal-app-after-upgrading-to-azure-sdk-26?forum=azuremobile&prof=required#de621720-3afc-458c-ba85-f691be9e74c1
I just got a new machine, and upon installing VS2013 (and I also tried VS2015 preview), one of our projects would not open.
The application which this project type is based on was not found.
Please try this link for further information:
http://go.microsoft.com/fwlink/?LinkId=441332&projecttype=CC5FD16D-436D-48AD-A40C-5A424C6E3E79
The output windows, gives this link, which is useless, and searching online for the GUID {CC5FD16D-436D-48AD-A40C-5A424C6E3E79} didn't bring anything up.
Any ideas what this could be? I have used Web Platform Installer to install the Latest Azure SDK.
It turns out that our project is based on Azure SDK 2.4, and I had incorrectly installed Azure SDK 2.5
Hopefully the GUID {CC5FD16D-436D-48AD-A40C-5A424C6E3E79} will show up in searches, if others have this same problem.
I'm having a problem on my TeamCity CI build server where during compilation I get the following error:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2342, 9): error MSB3086: Task could not find "AL.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
I've found similar reports from a year ago when people were upgrading to .NET 3.5, for example this one. In that case, installing the latest SDK solved the issue, however I have already installed the latest SDK (Microsoft Windows SDK for Windows 7 and .NET Framework 4) on my build server. The MSBuild tools are all there on the server, in a folder called
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
and AL.exe exists in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools
However the registry key mentioned in the error message does not exist. So, it seems like there is something wrong with the installation/configuration of MSBuild. This error only happens for projects that have embedded resources, which require AL.exe.
As you have install the latest SDK (I'm assuming that's v7.1)
Go to "Microsoft Windows SDK v7.1" from the Start menu
Select "Windows SDK 7.1 Command Prompt" and enter
cd Setup
WindowsSdkVer -version:v7.1
This will tell msbuild to use that version of the tools without needing to do any scary registry editing.
Even though the question is quite old but it still appears in the top of google search results so I decided to post my solution as well. I have trapped into same issue while during TeamCity setup on Windows Server 2016 and Windows 10 Pro.
I have installed Microsoft Build Tools 2015 and Windows 10 SDK (Only tools for .NET 4.6.2) and got the error from question.
The missing puzzle was to set environment variable: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.
After setting environment variable MSBuild was able to resolve all needed tools including AL.exe and build succeeded.
Please let me know if same can be achieved by setting values in registry, but otherwise environment variables also works very well in this case and no installation of VS is needed.
You also need to apply the following registry fix to update msbuild to point to the V7.1 sdk values.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1#InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86#InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDKNetFx35Tools#InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0#MSBuildToolsPath)"
I had the same problem there, here's my simple answer to this.
After you have installed the Microsoft Windows SDK 7.1 on the TeamCity Server.
In Regedit Change this key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
to
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx40Tools-x86#InstallationFolder)
Follow the below steps. This worked perfectly to me. Saved my time.
1- Right-click the My Computer icon and choose Properties, or in Windows Control Panel, choose System.
2- Choose Advanced system settings.
3- On the Advanced tab, click Environment Variables.
4- Click New to create a new environment variable under User variable section.
5- Variable name: TargetFrameworkSDKToolsDirectory
6- Variable value: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
Variable value depends on your SDK installation path.
7- Click OK and Save all windows.
8- Restart Visual Studio.
I have a simple, effective fix.
The problem seems to be that the tools version delivered with Visual Studio is version 7.0A, while the version delivered with the Windows SDK is version 7.1. That's all very well, but MSBuild.exe is still looking for the version 7.0A registry keys, which don't exist. This has to be a bug!
Looking in my registry, all the information for V6.0 and V7.1 is present and correct. So my solution is simple. I created a registry link that makes an alias of the 7.1 keys.
It's not possible to create registry links using the built-in tools, so I downloaded a little utility called 'regln' from here.
C:>regln-x86.exe "\Registry\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A" "\Registry
\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1"
Job done. MSBuild now works perfectly on the TeamCity server.
Add a system env variable TargetFrameworkSDKToolsDirectory
like this:
TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
restart VS
Ran into the same issue setting up a new build server on Windows 10.
Found and installed the latest (at the time) Microsoft Windows SDK for Windows 7 and .NET Framework 4 and that solved the problem.
We recently had this problem trying to get our .Net 4.0 builds working. We found that the location of al.exe had changed between where the original MSBuild that came with .Net 4.0 looks, and the Visual Studio SDK for .Net 4.0 (which was released later).
Since the only standalone installation of the SDK tools available is the one we had already installed without success (the one you mentioned), the only solution we could think of was to install Visual Studio on the build agents. We put Visual Studio 2010 Express (to keep the installation as lightweight as possible) on there and the problem went away. Not a pretty solution, but it did work - installing VS2010 also installs the SDK tools of the specific version that MSBuild appears to be looking for.
This is a problem that really shouldn't happen, but there didn't seem to be a way of making MSBuild look in the correct place for the tools, even hacking around in the registry.