It would appear that Visual Studio does not publish .ts files by default but does publish the .map files when using Web Deploy. I found an article which says I should add the following to the .csproj file:
<Target Name="AddTsToContent" AfterTargets="CompileTypeScript" Condition="'$(BuildingProject)' != 'false'">
<ItemGroup>
<Content Include="#(TypeScriptCompile)" Condition="'$(Configuration)'=='Debug'"/>
</ItemGroup>
</Target>
This did in fact seem to work as immediately after adding this the .ts files did in fact publish. Unfortunately I had to immediately remove the setting because after adding this none of typescript project includes worked anymore and the project wouldn't compile because all of a sudden all the path for references were wrong.
/// <reference path="../../sharedlibv2/sharedlibv2/ts/fb.core.ts" />
needed to be
/// <reference path="../../../../sharedlibv2/sharedlibv2/ts/fb.core.ts" />
in order to reference correctly. This path is completely invalid as it goes backward beyond the root of my hard drive, so clearly something is messed up. There are many hundreds of shared project files affected here and the reference this setting seems to require is not going to fly with others using these projects. I am guessing but haven't proven it that there will be other problems show up anyway.
I am using Visual Studio 15.5.7. Is there any other method of getting Visual Studio to publish .ts files via Web Deploy ?
Related
I have a large solution in which the "root" project includes feature projects by glob:
<ProjectReference Include="..\Feature\*\*.csproj" />
This works, despite not looking great in the references list, but the issue that occasionally Visual Studio will rewrite the csproj with all of the project references resolved:
<ProjectReference Include="..\Feature\A\A.csproj" />
<ProjectReference Include="..\Feature\B\B.csproj" />
It's not clear what triggers this, but I'm guessing it might have something to do with NuGet.
Is there anyway to stop VS from doing this (akin to using DisableFastUpToDateCheck for custom MSBuild scenarios)?
It's not clear what triggers this, but I'm guessing it might have something to do with NuGet.
It should be related to the items in the ItemGroup. I have the similar issue before, but the difference is that I use wildcards to contain .cs files and your are .csproj files, looks like:
<ItemGroup>
<Compile Include="**\*.cs" />
</ItemGroup>
When I delete one of .cs file in the <ItemGroup>, the wildcard gets expanded in the csproj file. For you case, if I deleted the the C.csproj project from Visual Studio (Add it before, reload the root project), then I got the same result as you.
For this issue, many other community members submit a user voice to Visual Studio team: VS IDE should support file patterns in project files. Now this is well supported in the new project system used by .NET Core and .NET Standard in Visual Studio 2017, but they haven't done the work to support it for existing project types.
Is there anyway to stop VS from doing this (akin to using DisableFastUpToDateCheck for custom MSBuild scenarios)?
To resolve this issue, you can use option Exclude="..." to exclude the project that you do not want to refer to:
<ItemGroup>
<ProjectReference Include="..\Feature\*\*.csproj" Exclude="..\Feature\C\C.csproj" />
</ItemGroup>
Or, if you want to delete one of project and keep the wildcard pattern, you only need to unload the root project, then delete the reference project, reload the root project, the wildcard pattern would be preserved.
Hope this helps.
I've done further research on this.
For testing, you can consistency reproduce the expansion by renaming any project that's included in the wildcard pattern.
Also, the easiest way to prevent the expansion is to:
Move the project reference globs into Directory.Build.props or another external file
Set DisableFastUpToDateCheck to true in your csproj
Using properties doesn't work and isn't required, likewise with using an Exclude.
I have a solution with multiple web projects. And there is common tsconfig which is used to build all typescript in solution. Build is called via webpack, so I don't want any typescript support from visual studio. More precisely, I want some support — in navigating and refactoring, but I don't want VS to build this code.
So I removed all references to typescript targets from csproj and everything works fine. But any time I add a new typescript file, VS gladly says
Your project has been configured to support TypeScript
and returns all typescript targets back to csproj.
Can I prevent VS from doing it? Of course I can live with it, but removing garbage from csproj after each adding seems uncomfortable.
UPD: found post on uservoice of VS https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/13420095-ask-to-configure-projects-for-typescript. But maybe there is solution already available. Or you can like this uservoice if you agree that it is an annoying problem :)
Found solution on uservoice (https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/13420095-ask-to-configure-projects-for-typescript).
Seems a bit ugly but it works.
Steps to fix:
Add some ts file to project and let VS add some bullshit to your csproj
ctrl-shift-s to make sure csproj is updated
Open csproj in any text editor and then:
Find import of Microsoft.TypeScript.Default.props and replace it's Condition="..." to Condition="false"
Remove line with TypeScriptToolsVersion
Find import of Microsoft.TypeScript.targets and replace it's Condition="..." to Condition="false"
Now after adding file VS will stop trying to do smth with project. And typescript will not be compiled on save and build, so you need to use gulp/webpack/grunt/whatever.
Visual Studio 2019 (16)
Add to *.csproj file
<ItemGroup>
<None Remove="**/*.ts" />
<Content Remove="**/*.ts" />
<TypeScriptCompile Include="**/*.ts" />
</ItemGroup>
Solution is described here: https://developercommunity.visualstudio.com/t/vs-modifies-csproj-file-with-typescriptcompile-ite/288648
I'm trying to automatically add an entire folder structure to a VS C++ makefile project. This isn't to make the project build (it'll always build from the scons file), I mostly want to use VS to edit the code/find in projects/intellisense etc.
I've tried the solutions suggested here : Is there a way to automatically include content files into asp.net project file? My project currently includes the tags
<ItemGroup>
<Content Include="$([System.IO.Directory]::GetFiles('$(ProjectDir)..\', '*.cpp', SearchOption.AllDirectories))" />
<Content Include="R:\src\FabricEngine\FabricUI\**\*.*" />
</ItemGroup>
But I haven't had any success - none of the suggestions give me the list of files in Visual Studio. Is this an MSBuild feature that isn't supported by VS perhaps? Or is it limited to managed products? Any suggestions on how to get this working?
Got similar problem and found that used following worked for me:
<None Include="$([System.IO.Directory]::GetFiles('$(MSBuildProjectDirectory)', '*.cpp', SearchOption.AllDirectories))" />
But issue with this is it just takes really long time and crashes if you have lot of files
I have a project that works that works as a subapplication on a site (actually multiple sites). Among other things, I have several static css and js files in this project. I need to keep those as separate js and css files, but to keep google happy, I'd like to minify those. Those files are likely to be modified in the future, so I'd like to avoid manually minifying them every time they are changed.
Is there some option that would allow me to minify those files on compile or publish (other than writing build events to minify those files using external tools).
The following pertains to VS2015, which has much better support for this scenario.
VS2015 introduces support for task runners like gulp or grunt. You could use one of those, and have a task triggered on project open (i.e. always runs while you're working on the project) which will itself monitor for file changes and run the minimizer (i.e. do it on save).
An intro to gulp in VS2015 is available here.
A simpler alternative on VS2015 is to use the Web Compiler Extension, which basically does the above automagically with less work on your side to set it up.
All solutions I found required using different filenames for the minimized versions, and a lot of extra work to switch between using the normal/minified versions.
Instead, I wanted the compressed JavaScript files to have the original names so I didn't have to change the references in my HTML markup. I could use the normal Javascript files in my development environment, then minimized versions would be automatically deployed when publishing.
I found a simple solution that does just that.
First, install Microsoft Ajax Minifier.
Then, in your Visual Studio project file, just before the closing </Project> tag add the following :
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Microsoft Ajax Minifier\ajaxmin.tasks" />
<Target Name="AfterBuild" Condition="'$(ConfigurationName)'=='Release'">
<ItemGroup>
<JS Include="**\*.js" Exclude="**\*.min.js;obj\**\*.*" />
<CSS Include="**\*.css" Exclude="**\*.min.css;obj\**\*.*" />
</ItemGroup>
<AjaxMin
JsSourceFiles="#(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".jsMIN"
CssSourceFiles="#(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".cssMIN" />
</Target>
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
</PropertyGroup>
<Target Name="CustomCollectFiles">
<ItemGroup>
<MinJS Include="**\*.jsMIN" />
<FilesForPackagingFromProject Include="%(MinJS.Identity)">
<DestinationRelativePath>%(RecursiveDir)%(Filename).js</DestinationRelativePath>
</FilesForPackagingFromProject>
<MinCSS Include="**\*.cssMIN" />
<FilesForPackagingFromProject Include="%(MinCSS.Identity)">
<DestinationRelativePath>%(RecursiveDir)%(Filename).css</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
What does the above code do? When you publish in Visual Studio, this code will find every .js and .css file in your source, and create a minified copy using the extension .jsMIN and .cssMIN. It will ignore files that are already minified. Then it will copy these minified files to the deployment folder, using the original file names.
Voilà! You just published minified JS/CSS files, while your original files stay intact on your development environment.
Optional:
Want Ajax Minifier to be packaged with your project? From the Ajax Minifier install folder, you can move AjaxMin.dll and AjaxMinTask.dll directly into your source directory. I put them in my App_Data folder. Once they're somewhere in your source, in Visual Studio right-click them, select Include in Project, and also change their Build Action property to None.
Then in the code I included above, change
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Microsoft Ajax Minifier\ajaxmin.tasks" />
to
<UsingTask TaskName="AjaxMin" AssemblyFile="$(MSBuildProjectDirectory)\App_Data\AjaxMinTask.dll" />
Done.
A troubleshooting tip:
My main code above executes AfterBuild and only when the configuration is Release. That's so it will only run during a publish. If your configuration is named something else, or you want it to run in other circumstances, modify the code as needed.
A nice tool can be downloaded from Visual studio Marketplace.
Bundler & Minifier
I'm trying to import a targets file from a relative path. The targets file is containing version information. The goal is not to have to modify all the thousands of projects files that we have when we create a new branch and have a new assembly version. We need the assembly versions because 2 version of the system can be installed at the same time and we have dlls in the global assembly cache.
Here's what it looks like in the project file:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\..\..\..\..\Versions.targets" />
...
<ItemGroup>
<Reference Include="MyDll, Version=$(VersionAssemblies), Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\..\..\..\..\..\..\..\..\Apps\$(CodeVersion)\DEVP\appl\BinApps\MyDll.dll</HintPath>
</Reference>
</ItemGroup>
...
</Project>
This is working fine if I'm working with a .vbproj. But the issue is that we have a lot of old .cobproj Cobol project files. For some reason, it seems like Visual Studio 2010 don't set the working directory when opening a cobproj, so it's unable to reach Versions.targets...
If I rename my cobproj to use vbproj as extension, it's working fine. So it's definitively something that Visual Studio is doing when a project of a known extension is opened, but I've searched a lot and I didn't find where I could add cobproj to tell Visual Studio that it's a known extension.
Another interesting fact, it that if I double click on my cobproj, it's working, because the working directory is already set to the directory in which the cobproj is... If I open Visual Studio and then do a File/Open and select my cobproj, then it's not working.
I'm wondering if someone may know how I could fix my issue without changing the extention of all my cobproj. I'd like a cleaner solution.
Thanks!
I've found a workaround, if I modify the Project Type Guid in the .sln, I can make Visual Studio act with my .cobproj like it would with a .vbproj, at least regarding the working directory setting.
From the .sln file:
Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "appsEXCI.Donnees.Containers.Cobol", "appsEXCI.Donnees.Containers.Cobol.cobproj", "{54E1DEC4-8919-40F6-B7BB-C936921B221F}"
EndProject