For a Visual Studio projects such as a ASP.NET MVC5, how do you disable compiling of TypeScript files on build/debug?
I currently have tsconfig.json compileOnSave and buildOnSave set to false. Does something need to be added to the projects .csproj to ensure it isn't compiled?
When debugging the ASP.NET MVC5 project, it compiles all .ts files.
Thank you for any help you can provide.
Add the property <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> to a PropertyGroup in your csproj file (I added it under the Configuration label). This should disable all msbuild based TS compilation.
With this setting enabled you shouldn't need the tsconfig.json settings compileOnSave/buildOnSave.
If you are on an older version of Visual Studio (I had implicitly thought about VS 2017 or xproj with 2015), the property may be <TypeScriptEnabled>false</TypeScriptEnabled>.
I had all of this configured, but it still did not fix the issue
(in visual studio 2019).
I added additionally this:
<TypeScriptCompileOnSaveEnabled>False</TypeScriptCompileOnSaveEnabled>
and restarted the visual studio. After that, it started working for me.
None of the other solutions worked for me and this one caused an error on project load (VS 2019 - 16.9.4)
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> // doesn't work for me
Another way of doing the same thing (albeit with very minor overhead) is to just remove all your TS from the compilation index.
<TypeScriptCompile Remove="*" />
I use this for avoiding compilation of node modules, like so:
<TypeScriptCompile Remove="node_modules\**" />
For Visual Studio 2015, adding below line under PropertyGroup helped me.
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
I had this issue, tested all the things that was posted here without success,
But after adding this, things worked:
<TypeScriptToolsVersion>3.9</TypeScriptToolsVersion>
Seems like the version that I was using did compile no matter the settings.
Next approach worked for me (.NET 6, VS2022, ASP.NET Core + Angular project).
Add this setting to your *.csproj file:
<PropertyGroup>
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
</PropertyGroup>
Related
Hi Stackoverflow Community,
I am trying to build my Web and WebAPI, console applications with Target Framework - .NET Core 3.0, as per project 'Application' properties, using:
Microsoft Visual Studio Community 2019
Version 16.5.4 on Windows 10 PRO
I am seeing the following errors:
Error MSB3030 Could not copy the file "C:\Users...\WebApi3\obj\Debug\netcoreapp3.0\webapi3.exe" because it was not found
and
Error MSB3030 Could not copy the file "C:\Users...\Web\obj\Debug\netcoreapp3.0\webportal.exe" because it was not found
Hence these projects are not getting built.
Appreciate your time for reading this.
Please advise.
Here is the part of the code where the error points to:
============================================================
_CopyOutOfDateSourceItemsToOutputDirectory
Copy files that have the CopyToOutputDirectory attribute set to 'PreserveNewest'.
============================================================
-->
<Target
Name="_CopyOutOfDateSourceItemsToOutputDirectory"
Condition=" '#(_SourceItemsToCopyToOutputDirectory)' != '' "
Inputs="#(_SourceItemsToCopyToOutputDirectory)"
Outputs="#(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')">
<!--
Not using SkipUnchangedFiles="true" because the application may want to change
one of these files and not have an incremental build replace it.
-->
<Copy
SourceFiles = "#(_SourceItemsToCopyToOutputDirectory)"
DestinationFiles = "#(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
UseSymboliclinksIfPossible="$(CreateSymbolicLinksForAdditionalFilesIfPossible)"
>
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
</Target>
I faced the same issue in VS2022(17.0.1) as well. I performed below steps based on a github issue [https://github.com/dotnet/sdk/issues/3122] discussion and my issue got resolved. I believe this works for VS2019 as well.
Step1: Clean Local Nuget Cache
..\projectDir> dotnet nuget locals all --clear
Step2: remove bin and Obj folders
..\projectDir> rd \s \q bin obj
Step3: Clean the solution using Visual studio build menu
Step4: Rebuild Project
Updating Visual Studio to 16.5.5. seems to have solved the issue so far.
I had a similar issue but whilst attempting to publish. The affected .DLL was a nuget package and I noticed I had an update for it.
Updating the affected package, cleaning the solution, rebuilding then re-publishing resolved my issue.
For CoreXT repos by default only outputs under obj for retail builds or objd for debug builds are collected. You seem to be using the retail bridge and using obj(Debug|Release) and bin (the MSBuild non-CoreXT defaults), so those outputs are not being collected.
To remedy this, you can set the -UsePredictedOutputPath QuickBuild flag which will avoid collecting those hard-coded paths and instead ask each project what its $(IntermediateOutputPath) and $(OutputPath) are and use those.
Note that in either case, outputs under output roots (eg /target) are always collected. This flag only affects the project-relative outputs.
I started out creating a .NET Standard Library that I intended to make a NuGet of - but came to find that I also needed platform-specific functionality.
So, I found this stack overflow question - which indicated I could use a Multiplatform Librarytemplate instead. But here I encountered a problem with DependencyService - and a problem with Custom Renderer - effectively meaning that there was no way for the non-platform-specific to communicate with platform-specific code in the library.
I also tried to edit the csproj file, examples: A, B, C. And by using the following csproj:
<Project Sdk="MSBuild.Sdk.Extras/2.0.29">
<PropertyGroup>
<TargetFrameworks>netstandard2.0;Xamarin.ios10</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Xamarin.Forms" Version="4.1.0.581479" />
</ItemGroup>
</Project>
... the following solution is generated:
But in Class1 the Xamarin.iOS nor Xamarin.Forms.Platform.iOS can be accessed in Visual Studio for Mac. And I recently checked and could see that it worked in Visual Studio on windows - using the same csproj.
Is there any way to multitarget in Visual Studio for Mac?
Edit 1:
I found an issue on MSBuild.Sdk.Extras on GitHub leading to this post. It seems a certain extension can be installed called DotNetCoreSupportAnyTargetFramework.DotNetCoreSupportAnyTargetFramework_1.0. But it won't be installed correctly in VSfM 8.1.5:
Trying it out in older VSfM I can't open project or create new ones - so I can't test to see if the extension works. It could be related to the following error message:
that shows when opening the old VSfM.
Edit 2: After changing the order the target frameworks are given in - placing Xamarin.ios10 first - the Xamarin.iOS and Xamarin.Forms.Platform.iOS became accessible - as mentioned by Matt Ward.
However I can't add reference to the NetStandard Library to a Xamarin.Forms project to actually test the library:
And switching back to having netstandard placed first:
Projects/MyStandardLibrary/MyStandardLibrary/MyButtonRender.cs(12,12): Error CS0246: The type or namespace name'ExportRendererAttribute' could not be found (are you missing a using directive or an assembly reference?) (CS0246) (MyStandardLibrary) etc.
The current release of Visual Studio for Mac, v8.2, does not support Multi-Targeting.
According to the Visual Studio for Mac Roadmap, Multi-Targeting support will be available in Visual Studio for Mac v8.3:
https://learn.microsoft.com/visualstudio/productinfo/mac-roadmap#2019-q3-july-september
Edit: You can follow the team's progress on adding Multi Targeting support here: https://github.com/mono/monodevelop/pull/7848
I created an MVC/Web API project in VS 2013. When I try to open that solution with Monodevelop, it fails with error "There must be 2, 3 or 4 components in the version string.". It's because of the references in .csproj file such as <Reference Include="System.Net.Http.Formatting, Version=__MvcPagesVersion__, ..."> ... </Reference>.
How can I fix those references so that it can be compiled with Monodevelop? Is it safe just to remove Version string from those references?
Ran into a similar problem just now. __MvcPagesVersion__ must be some placeholder Visual Studio uses in the *.csproj files. I combed through the csproj file that wouldn't load in Xamarin Studio and replaced all the references to __MvcPagesVersion__ with "5.2.0.0" without the quotes. I then reloaded the project and everything seems to be working for me now.
First some background. At the end of 2012 we migrated our vs2008 solution to vs2010 but we still target .NET 3.5. (I know nothing but the latest and greatest here!)
We hadn't had any issues with this setup until a few weeks ago when people started getting these errors:
"foo.csproj" (Rebuild target) (16:5) ->
C:\...\foo.csproj(142,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The interesting thing is that if you look at the project file it references v10 which makes sense because we don't use Visual Studio 2012.
This error hit several of us at once and even on older code branches that haven't changed in months.
I suspect some update got pushed onto our machines that confused things but I don't know what to do about it.
The short term solution has been to install VS 2012 and not use it but I'm hoping for something a little cleaner than that.
I ran into the same issue with Visual Studio 2013. It turns out that I was using the old version of MSBuild--the one that ships with the .NET Framework--from the command line. Microsoft is now releasing MSBuild as part of Visual Studio itself and also as a separate installer (http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx).
The solution was to use the new version of MSBuild.exe located in C:\Program Files (x86)\MSBuild\12.0\Bin. Once I did that, all the targets errors disappeared.
EDIT 1
As mentioned in the comments, each new version of MSBuild brings with it a new directory. For Visual Studio 2015, use C:\Program Files (x86)\MSBuild\14.0\Bin.
EDIT 2
As mentioned in the comments, for Visual Studio 2017, use C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.
If you have a build server that does not have VS2012 installed, you can fix this by
a) installing the MSBuild.Microsoft.VisualStudio.Web.targets package to your solution, and
b) replacing this line in the .csproj file:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
With this line pointing to the nuget package
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />
EDIT
As #joedragons points out the version in the updated line should match the nuget package version, i.e. replace targets.11.0.2.1 with targets.x.x.x.x for the current version.
A simple solution to this problem:
Go to the following path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio
You will see the latest version V10.0, v11.0, v12.0 depending on your Visual Studio 2010, 2012 or 2013 install.
Copy WebApplications folder from either of latest version directory and paste to other.
Your issues should be resolved.
I've found that installing the free Visual Studio 2012 Shell (Isolated) installs the WebApplications v11 MSBuild files. Lighter than a full install of Visual Studio 2012 and no licensing concerns.
Wow. We just saw the same thing happen on our build machine. We use VS2010 and target .NET 4.0. Our project files explicitly import the v10.0 version of these targets. With no changes to the code, yesterday the build was fine and today it's failing with a complaint about a missing v11.0 version. The .NET Framework 4.5.1 got installed/updated last night on this build machine as an automatic update. We're going to force v10.0 with the parameter (or env. variable), but this certainly took us by surprise...
UPDATE: What's even more weird, is that it seems to be the case that today's version of msbuild seems to be using the first line of the sln file to determine which VisualStudioVersion to use by default, whereas yesterday's version did not:
Format Version 12.00
We tested manually changing this to 11.00 and the build started working again.
In our case, even though we're targeting and building everything for 2010/4.0, some devs have been getting ready for VS2012 (since MS claimed that the project files are compatible), and this particular solution was last saved (months ago) in VS2012. Before today, that wasn't causing a problem.
I had the same issue. Fixed by going through above listed solutions. The issue is caused because appropriate version of Visual Studio Tools (BuildTools) is not available on the Build server. As rightly pointed above, this can be resolved by installing BuildTools but is not the option in my case.
Here is another alternative - use Nuget
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3
Identify the start up project and Install the web.targets based on the version of Visual studio being used.
The following files will be modified which includes the required changes
In packages.config:
<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />
In .csproj:
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />
Hope this helps!!! Good Luck,
Cheers,
Hack, but solved it by copying:
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications*.*
to
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications*.*
I got this error in the end of November without making any changes to either the configuration of my TeamCity installation or MSBuild installation or the source code. On my build server Visual Studio isn't even installed, and the change from VS2010 to VS2012 was made in the end of August without any problems at the time.
My MSBuild version is 4.0.30319.18408, my build server is a Windows Server 2008 R2 SP1 with TeamCity v6.5.3.
I solved the issued by simply copying the v11-folder from another build server which was unaffected.
My guess is that this could have happened in two ways:
Something was updated which triggered a deletion of the v11-folder. Could it be a Windows Update to .NET or something?
Something was updated which changed my TeamCity/MSBuild configuration from using v10 to v11 and the builds stop working as the v11 never existed.
I've got a update to .NET Framework 4.5.1 on December 3rd, could that be the reason?
Brgds
Jonas
I've recently got stuck with the same problem. And my conclusion is that every version of VS (v10, v11, v12) changes path of build variable, like MSBuildBinPath.
So specifying exact version of VS isn't a hack, because you might not even have appropriate version of files installed. So intead you'd better specify a parameter and use targets that exist on you machine.
In some rare cases you might need to install specific version of VS and Web Deploy package. In my case just version was enough to solve problem.
You can add the VisualStudioVersion property like this:
<ItemGroup>
<ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
<Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
</ProjectToBuild>
</ItemGroup>
<MSBuild Projects="#(ProjectToBuild)" Targets="Rebuild"/>
As I was searching how to solve this one, almost everyone recommended either to copy the missing MSBUILD folder or install some SDK of some version.
Luckily, I've found this awesomely helpful post by Donovan Brown :
http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!
In a nutshell, the idea is to configure the VisualStudio version your build should use in your Build Definition:
Right Click -> "Edit Build Definition..."
Go to "Procss" -> "3. Advanced"
and set "MSBuild Arguments" with
/p:VisualStudioVersion=12.0
I am wanting to use Visual Web Developer Express 2010 to publish a website, pre-compiled to a remote server over FTP using the following settings:
Deploy only files needed to run this application
Precompile this application before publishing
Allow website to be updatable
No databases are being deployed
Site is being deployed as file hierarchy, not as .zip package
My first build/deploy seemed to have gone well, but after my second compilation I receive the following error:
Transformed web.config using C:\path_to_site\Web.Debug.config into obj\Debug\TransformWebConfig\transformed\web.config.
Copying all files to temporary location below for package/publish:
obj\Debug\AspnetCompileMerge\Source.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.5\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets(132,5): Error : Can't find the valid AspnetMergePath
And here's a subset of the content of the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file:
<Target
Name="GetAspNetMergePath"
DependsOnTargets="$(GetAspNetMergePathDependsOn)"
Condition ="'$(GetAspNetMergePath)' != 'false'">
<PropertyGroup>
<AspnetMergeName>aspnet_merge.exe</AspnetMergeName>
<AspnetMergePath Condition="Exists('$(TargetFrameworkSDKToolsDirectory)$(AspnetMergeName)')">$(TargetFrameworkSDKToolsDirectory)</AspnetMergePath>
</PropertyGroup>
<Error Condition="'$(AspnetMergePath)' == '' Or !Exists($(AspnetMergePath))"
Text="Can't find the valid AspnetMergePath" />
</Target>
EDIT: Changing the publish settings to delete all existing files before publishing does not fix the problem after all. I'm assuming that the problem is local for now because of this.
There does not appear to be an AspMergePath tag in my web.config. I am not aware if I am supposed to manually add the tag. However, the path "obj{publish setting}\AspnetCompileMerge\Source" does exist in my project.
And in case it matters, my project name is "TestProject.NET"
Your feedback is appreciated.
I hit the same problem. Searched through all microsoft related sites, found a lot of complaints and no intention from microsoft to fix it.
Here how I worked it around at my system. Edit the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file and add the following line. Please make sure that the Microsoft SDK path is the same on your PC, if not then change it:
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\</TargetFrameworkSDKToolsDirectory>
Here is how it should look like:
<Target
Name="GetAspNetMergePath"
DependsOnTargets="$(GetAspNetMergePathDependsOn)"
Condition ="'$(GetAspNetMergePath)' != 'false'">
<PropertyGroup>
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\</TargetFrameworkSDKToolsDirectory>
<AspnetMergeName>aspnet_merge.exe</AspnetMergeName>
<AspnetMergePath Condition="Exists('$(TargetFrameworkSDKToolsDirectory)$(AspnetMergeName)')">$(TargetFrameworkSDKToolsDirectory)</AspnetMergePath>
</PropertyGroup>
<Error Condition="'$(AspnetMergePath)' == '' Or !Exists($(AspnetMergePath))"
Text="Can't find the valid AspnetMergePath" />
What you need is aspnet_merge.exe, tool that is distributed as part of Windows SDK. It's intended to precompile sites, so you can either turn that precompilation off, or install proper version of Windows SDK. Reference is to the Wikipedia, because of nice prepared links to the download pages. You don't need to download/install everything (it's huge), just download web installer and select .Net tools, it will take around 50 megabytes.
Please, notice that bundled with Visual Studio 2010 Windows SDK ver. 7.0A isn't available to separate download, so you'll have to either install Visual Studio on your build server, or tweak something as described in answers to "Running MSBuild fails to read SDKToolsPath".
Here is a solution that does not require changing the targets file. The workaround from http://connect.microsoft.com/VisualStudio/feedback/details/786492/publish-cant-find-the-valid-aspnetmergepath suggests passing additional properteries to msbuild. I was able to get it to work using this:
msbuild website.publishproj /p:DeployOnBuild=true /p:PublishProfile=Release /p:VisualStudioVersion=12.0 /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\"
The key here is the AspnetMergePath property, which you may need to change if the Windows SDK is installed in a different location. If I include the GetAspNetMergePath property from the workaround it fails, but that may be needed depending on the SDK version.
One workaround for all this stuff [including having to install the SDK etc] is to disable the Precompile On Publish option, which requires AspNetMerge to be present even if you're not specifying that you want stuff to be merged in the ultimate output.
I was going to great lengths to figure out how to turn it off, poring over the options dialog and Reading the Friendly Manual to confirm I had it turned off for ages only to realize it was the checkbox outside:
Unchecking yields the following changes to the .pubxml:
- <PrecompileBeforePublish>True</PrecompileBeforePublish>
- <EnableUpdateable>True</EnableUpdateable>
- <DebugSymbols>False</DebugSymbols>
- <WDPMergeOption>DonotMerge</WDPMergeOption>
Which worked for me.
NB it is however critical to have as covered here both the Web (which will silently make publishing via /p:DeployOnBuild inert) and the WebApplications (which will give a compiler error) subfolders present under %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v14.0 (assuming Visual Studio 2015 tooling) for publishing to successfully generate packages
I hit the same problem.
Edit the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file and add the following line. Make sure run editor with Administrator Rights.
Looks the correct versión Visual Studio in my case VS2013.
x64
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\</TargetFrameworkSDKToolsDirectory>
x86
<TargetFrameworkSDKToolsDirectory>C:\Program Files\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\</TargetFrameworkSDKToolsDirectory>
And it Works! I can compile my Project.
In my case was missing. It happened after updating Visual Studio 2017 to 15.7.5. Before that it was working fine. I have to add
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\</TargetFrameworkSDKToolsDirectory>
It was at Line no 129 in Microsoft.Web.Publishing.AspNetCompileMerge.targets
change targetFramework ...
<compilation debug="true" targetFramework="4.8"/>
<httpRuntime targetFramework="4.8"/>