Yesterday I was debugging a service on a remote machine and now that I have corrected the problem I need to continue working on the code on my local machine. But now when I hit F5 the error "The Visual Studio 2019 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall..." is displayed.
I checked the options under Debug - Attach to Process but there is no option to disable remote debugging. How can I get rid of this message?
I also tried Start Without Debugging (Ctrl-F5) thinking I could attach to the process once it had started but I got the same error and the code wouldn't run.
I can debug other applications on the same PC - just not the code I used to debug the remote machine. There are no changes in the project file but copying the code to another directory and excluding the .vs directory didn't help.
VS2019 created a <ApplicationName>.csproj.user file which contained the remote debugging information;
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="Current" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProjectView>ProjectFiles</ProjectView>
<PublishUrlHistory>publish\</PublishUrlHistory>
<InstallUrlHistory />
<SupportUrlHistory />
<UpdateUrlHistory />
<BootstrapperUrlHistory />
<ErrorReportUrlHistory />
<FallbackCulture>en-US</FallbackCulture>
<VerifyUploadedFiles>false</VerifyUploadedFiles>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
<RemoteDebugEnabled>true</RemoteDebugEnabled>
<RemoteDebugMachine>SXCRM:4024</RemoteDebugMachine>
</PropertyGroup>
</Project>
Deleting this file or disabling the RemoteDebugEnabled property resolved the issue.
Related
I am new to VS code/F# and I am trying to build a F# console app (on both Windows workstation and on my Linux computer).
I installed the Ionide extension together with FAKE.
The code I am considering is the Iris example (see How to translate the intro ML.Net demo to F#?), creating a New F# Project with Ionide and using Microsoft.ML.
My iris.fsproj is
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net461</TargetFramework>
<DebugType>portable</DebugType>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>
<ItemGroup>
<Compile Include="iris.fs" />
<None Include="App.config" />
</ItemGroup>
<Import Project="..\.paket\Paket.Restore.targets" />
</Project>
When running the script (which I do with the "play" button aka F#: run script provided with VS Code/Ionide) I get:
C:\Users\MyUser\.nuget\packages\microsoft.ml\0.2.0\build\Microsoft.ML.targets(16,5): error : Microsoft.ML currently supports 'x64' processor architectures. Please ensure your application is targeting 'x64'.
together with
Running build failed.
Error:
System.Exception: dotnet build failed
How do I target x64 with the project structure provided by Ionide?
It should be as simple as adding the following line to your PropertyGroup section:
<PlatformTarget>x64</PlatformTarget>
There are more complicated setups possible using the Condition attribute to set the platform target based on various command-line arguments to the compiler, but that should be the simplest way to get you up and running.
I got an error during the deploying my web-application.
The title of error is Could not open Source file: Could not find a part of the path
'Could not open Source file: Could not find a part of the path
'E:\ARCHIVES\Projects\Main\Jahan.Handicraft\Jahan.Handicraft.Web.Mvc.UmbracoCms.App\obj\Release\AspnetCompileMerge\TempBuildDir\App_Plugins\UmbracoForms\Data\Web.config;\App_Plugins\UmbracoForms\Data\Web.config'.'.
I've used Umbraco 7.4.3 und ASP.NET MVC in my project.
I'd like deploy it on localhost.
How can I solve this problem?
This is a failed attempt at transforming connection strings in sublevel configurations files.
To disable this transformation, edit the publish profile under Properties\PublishProfiles and set the value of the AutoParameterizationWebConfigConnectionStrings element to false. Add the element if missing.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<!--
...
Other settings
...
-->
<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>
</PropertyGroup>
</Project>
I got it from this blog (which is not mine): http://blog.aabech.no/archive/web-deploy-says-could-not-open-source-file-some-webconfig-when-you-publish-an-umbraco-site/
Post installation
You should note that the Umbraco nuget package adds a build step to always include the Umbraco folders when you deploy using Web One-Click Publish with Visual Studio.
You can see these folders in packages/UmbracoCms x.y.z/build/UmbracoCms.targets
Should you need to exclude any of these folders or content, you can add a target to your .pubxml files in the properties/Publish folder. For instance if you need to exclude json data a plugin generates during production.
<Target Name="StopUmbracoFromPublishingAppPlugins" AfterTargets="AddUmbracoFilesToOutput">
<ItemGroup>
<FilesForPackagingFromProject Remove=".\App_Plugins\UmbracoForms\Data\**\*.*"/>
</ItemGroup>
</Target>
Reference: https://our.umbraco.org/documentation/Getting-Started/Setup/Install/install-umbraco-with-nuget#post-installation
I am getting following error while building project in Team city.
Same project is getting build on Local machine. Local machine has VS 2015 and F# 4.0.
My Project Configuration is as below.
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<Choose>
<When Condition="'$(VisualStudioVersion)' == '11.0'">
<PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.Targets')">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets')">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</Otherwise>
</Choose>
<Import Project="$(FSharpTargetsPath)" />
This is Console application.
I had a similar problem a while back, because I was running the local machine with Administrator privileges, but the Visual Studio installer had set environment variables at the user level and not the system level which Administrator uses. So when compiling as Administrator, the FSharpTargetsPath was not being correctly built from environment variables like VisualStudioVersion.
Have a look on your local machine to see what environment variables values are set for VisualStudioVersion at the level you are successfully using (System or User), as well as other variables and then check that these are set at the corresponding level on the Team City machine.
Perhaps you are running as user on your local machine and System on the Team City machine.
See details here: https://stackoverflow.com/a/21420306/152739
I hope this makes sense.
I checked the middle option, below, "Precompile during publishing".
This changed the FDeploy.pubxml file by a few lines. Fine. I committed this single change to my build server.
Heres the pubxml:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>C:\Temp</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>False</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
</PropertyGroup>
</Project>
The remote build with mvcbuildviews enabled passed. The remote deploy failed with errors like:
Error 82 The name 'ViewBag' does not exist in the current context
Error 5 The name 'model' does not exist in the current context
and so on. There's over 100 errors like this. Keep in mind the regular msbuildviews enabled msbuild step worked fine with the same code.
I use msbuild on the web project csproj this way:
/p:DeployOnBuild=true /p:PublishProfile=FDeploy /p:VisualStudioVersion=12.0 /p:Configuration=Release
Any clues? Oh yeah, checking the box caused the same errors on my dev machine as well, I had to delete the bin, obj and appdata folders completely to neutralize it. However, doing a fresh checkout on the build server did not help.
Also note that when I went back to my old deploy profile it took a fresh checkout to fix the deploy.
I had to cheat to solve this problem: I restricted my use of MvcBuildViews to only the 'Debug' version of the project:
In the csproj file:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>
I ran into other inexplicable errors using mvcbuildviews when deploying. Seems best to avoid using it altogether. Anyway, the build is still kept clean because I compile and test the debug version too.
We upgraded to TFS 2012 and changed our legacy build templates to remove all strong name references to Microsoft.TeamFoundation namespaces from the Activity element. We are now getting the following error when building:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets (801): The "CreateWorkspaceTask" task was not given a value for the required parameter "BuildAgentUri".
Has anyone else encountered this error?
I just resolved this issue earlier today....
Navigate and open:-
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets
Find the section resembling the following:-
CreateWorkspaceTask
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
BuildDirectory="$(BuildDirectory)"
SourcesDirectory="$(SolutionRoot)"
Name="$(WorkspaceName)"
Comment="$(CreateWorkspaceTaskComment)"
Replace it with:-
<!-- Create the workspace for this build -->
<CreateWorkspaceTask
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
BuildDirectory="$(BuildDirectory)"
SourcesDirectory="$(SolutionRoot)"
Name="$(WorkspaceName)"
Comment="$(CreateWorkspaceTaskComment)"
Condition=" '$(ProjectFileVersion)' != '4'">
<Output TaskParameter="Name" PropertyName="WorkspaceName" />
<Output TaskParameter="Owner" PropertyName="WorkspaceOwner" />
</CreateWorkspaceTask>
<CreateWorkspaceTask
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
BuildDirectory="$(BuildDirectory)"
BuildAgentUri="$(BuildAgentUri)"
SourcesDirectory="$(SolutionRoot)"
Name="$(WorkspaceName)"
Comment="$(CreateWorkspaceTaskComment)"
Condition=" '$(ProjectFileVersion)' == '4'">
<Output TaskParameter="Name" PropertyName="WorkspaceName" />
<Output TaskParameter="Owner" PropertyName="WorkspaceOwner" />
</CreateWorkspaceTask>
Please pay special attention to the casing of the text as this is an XML document...
Please let me know if this helps...
Cheers!
...
Chev
We ran into this same issue on one of our build machines. The build machine was working fine one day and stopped the next. The only change was finishing the installation of Service Pack 1 for Visual Studio 2010.
We figured that possibly MSBuild got rolled to a previous version.
So we looked at this file on another build machine and that section looked exactly like the snippet Chev provided.
So we went into "progams and features" on the build machine and did a Repair on the TFS 2012 installation. That updated the Microsoft.TeamFoundation.Build.targets file to look just like the snippet provided by Chev.
Now the builds run correctly again.