VS 2017 often fails refreshing ASP.NET Core web applications with the following error message:
Beginning retry 1 in 1000ms.
...
Beginning retry 10 in 1000ms.
but when the second try, it runs ok.
Question how to change/customize the configuration values of CopyRetryCount and CopyRetryDelayMilliseconds in a project?
I found a global settings in the file,
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
but what is the appropriate way to define a project level settings about those two?
If you want to override those two properties, you can in your project *.csproj file. It will look like this:
<PropertyGroup>
<CopyRetryCount>2</CopyRetryCount>
<CopyRetryDelayMilliseconds>Put some number here</CopyRetryDelayMilliseconds>
</PropertyGroup>
You just hand edit your csproj file and put those values in there yourself.
Related
So I just made some c++ application, using NotificationIcon sample from Microsoft as a reference, and thus I'm stuck with the NotificationIcon.exe output file. The name is really lame and I'd like to change it. I've tried renaming the exe, renaming the solution, the project - whatever else - and my programm just exited with code 0x00 after building. What else should I try?
I tried to do the same thing, but there were a few steps I had to follow in VS2019 just to get set up. If you are not in a similar state, the rest of the answer might not apply.
Downloading the sample: I had to install the Windows 7 SDK, as the download page didn't seem to exist anymore. I'm not sure if you found it elsewhere, in which case you might be starting from different sources.
Converting the .vcproj file to .vcxproj. Visual Studio no longer supports .vcproj, and opening the solution triggered this conversion automatically.
Now, once I have a .vcxproj file, there are two routes to setting the name of the exe:
Right-click the project in VS, click Properties, and find the Target Name field. This defaults to $(ProjectName) so I would have expected that renaming the .vcxproj would have renamed the .exe file.
Edit the .vcxproj file directly, adding <TargetName>Foo</TargetName> into the section that starts with <PropertyGroup Label="Globals">
Working on a project using Visual Studio as my IDE. It has an API component written in C#, and a webserver component that uses TypeScript.
I am using webpack to deal with the typescript compilation and would like to remove the Visual Studio build step from the typescript files.
Normally I wouldn't care if it was building them, but I am using Typescript > 1.8.4 which has language features that Visual Studio cannot understand which is making Visual Studio throw errors and prevent compilation. I found a workaround for this in this github issue thread but I have other developers cross team who are working on this and trying to coordinate a hack to make code among them will not work.
I have also tried removing the typescript imports line from the .csproj file, but whenever I add a new ts file, it adds the line back in.
Is there a way to completely shut down the typescript compilation/parsing step in Visual Studio and prevent it from coming back?
This in in VS 2015.
You can disable typescript compilation by editing the .csproj file to contain the following:
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
That should disable all typescript compilation within VS 2015.
To disable TypeScript compilation altogether for Visual Studio, edit:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\TypeScript\Microsoft.TypeScript.targets
(Your path might be slightly different depending on your OS/VS version, in that case just search for Microsoft.TypeScript.targets)
And add:
<PropertyGroup>
<TypeScriptCompileBlocked>True</TypeScriptCompileBlocked>
</PropertyGroup>
This works for .NET Core projects as well.
It seems that the errors are triggered by IntelliSense and one can remove IntelliSense errors by simply filtering the list.
In case that other solutions doesn't help this is the key to clean up the error list, at least temporarily.
Sam Storie's answer is a great start and it will stop typescript errors from preventing compilation, but Visual Studio will still report the parsing errors which will prevent the ability to use the built in publishing tools.
To completely remove error reporting in ts, find all import lines in the csproj that reference typescript and set the Condition property to false, make sure to restart VS afterwards:
Example:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="false" />
Remove / Uncheck Test Javascript Content Files from the Project filter.
Is it possible to use an external build system for VC++ 2013?
I want Visual Studio do nothing but build by invoking my build tools.
I am thinking about something like this:
Put all build command in batches.
Invoke a project-level build batch by right clicking the project and choose build.
Invoke the a solution-level build batch by right clicking the solution and choose build.
Is there some walk-through tutorial? I searched a lot but no luck.
ADD 1 - Some progress...
After briefly reading about the MSBuild process, I tried as below.
First, I edit the *.vcxproj project file. I change the DefaultTargets from Build to MyTarget.
<Project DefaultTargets="MyTarget" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Then I add a new target named MyTarget:
<Target Name="MyTarget">
<Message Text="Hello, Bitch!" />
</Target>
I hope this can bypass the VS2013 built-in built process and only carry out my own batch.
It works well on command prompt:
But in Visual Studio, when I right click the project and choose build command, it gives me a lot of link errors.
How to avoid these link errors? Since my batch can take care of all the build process, I don't need Visual Studio to do the link for me.
ADD 2
It seems these link errors show up because I include the *.c files with the ClCompile tag as below.
<ItemGroup>
<ClCompile Include="z:\MyProject1\source1.c" />
<ItemGroup>
Since I don't want VS2013 to invoke the compiler, I change it to <ClInclude> tag, the link errors disappeared, but the symbol resolution is not working... Seems I shouldn't change the tag.
ADD 3
Here's another way to compile without linking.
Is it possible for Visual Studio C++ to compile objects without linking
Seems it doesn't have the symbol resolution issue. But I still cannot invoke an external batch by click build/rebuild/clean.
You might want to look into Visual Studio's makefile projects (in the Visual C++/General project templates category).
You get to specify what commands to execute for each type of build (clean, build, rebuild). The command can invoke a make, run a batch file, or invoke some other build tool. It just executes a command. The commands can contain various macros that VS provides (similar to environment variables) so the command can be parametrized for things like making a target directory based on the solution or project name or type (debug vs. release).
(Michael Burr's reply pointed out a better direction, i.e. a better VC++ project template. You can combine my answer and his.)
Finally, I solved this issue!
The trick is the so-called target overriding. The Visual Studio context menu items Build\Rebuild\Clean correspond to MSBuild targets named Build\Rebuild\Clean, respectively. We just need to override them in the *.vcxproj file.
Such as this:
DO REMEMBER that:
The last target seen by MSBuild is the one that is used — this is why
we put the at the end of the existing *.vcxproj file.
And in the override.proj, do whatever you like as below:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text="Build override!" />
<Exec Command="kickass.bat" />
</Target>
</Project>
The following 2 links are good reference:
Hack the build
Hijacking the Visual Studio Build Process
Note that:
The 1st link take a CSharp project as example, but ALSO works with VC++ project.
The 2nd link doesn't work for VC++ project but the rational is similar. If you didn't include the Microsoft.Cpp.targets, you will see the following error when loading the project:
ADD 1
As I tried, we don't need another overrride.proj file. We can just place the specific target at the end of the *.vcxprj file. Such as below:
ADD 2
With target overriding mentioned above, I can run my customized bat file with project's Build/Rebuild/Clean commands. But I noticed that when I run solution's Build/Rebuild/Clean commands, I think it is just following some kind of project dependency order to build each project respectively, which is not exactly equivalent to what I want for an overall build in my scenario.
My current workaround is to create a dummy project and use it to trigger a batch for my overall build.
I am attempting to overhaul my project's build processes. We have ~330 Visual C++ projects that we have upgraded in the last year from Visual Studio 2005 to Visual Studio 2013. I would like to take advantage of MSBuild to improve our build time over our very serial build scripts that we have now. I have completed a rough first pass and dropped the build times for a Release build from ~2 hours to ~20 minutes. In the process of doing this, I am consolidating a lot of common project settings into a .props file . In doing so, I have hit a stumbling block.
I wish to inherit the Platform Toolset from one VSProps file to all of the projects that include it. At the top of the new .props file I created, I put the following:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="Configuration">
<PlatformToolSet>v120</PlatformToolSet>
</PropertyGroup>
<PropertyGroup Label="UserMacros" />
I then removed the corresponding <PlatformToolSet>v120</PlatformToolset> from the individual project files.
Alas, things have started to go downhill. The projects (in Visual Studio 2013) now say in the Solution Explorer something like CoreGeometry (Visual Studio 2010) and the projects themselves seem to want to reference the v100 platform toolset. When I build, it then complains at me:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets(362,5): warning MSB8003: Could not find WindowsSDKDir variable from the registry. TargetFrameworkVersion or PlatformToolset may be set to an invalid version number.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(341,5): error MSB6006: "CL.exe" exited with code -1073741515.
The only way I have been able to work around this is to manually set the PlatformToolset on the .vcxproj themselves, which is not terrible, I just am a bit annoyed that every other property seems to inherit, but the PlatformToolset does not.
My question is thus:
Can I use a .props file to inherit a common PlatformToolSet into a .vcxproj that does not specify a platform toolset?
A second question: Should I even be messing with the Platform ToolSet in this manner or am I setting myself up at risk for a maintenance nightmare later?
It is very good practice to extract common settings to a separate .props file and <Import> that from all projects. I am doing the same with my projects, including configuring PlatformToolset property in .props file, and I have no problems building it this way.
Few points related to this:
There is nothing special about PlatformToolset property, or any other property for that matter. Configuring properties inside .props file is identical to setting it inside .vcxproj file directly (however see my point below about ordering). Of course, there are some built-in properties, which you cannot configure at all, but those are always read-only properties.
The only case where you would not be able to override a property, if it the property value is passed directly from command line for the build (e.g. msbuild mysolution.sln /p:Platform=x86 will have everything built with Platform property set to x86 and overrides in projects won't take effect).
There is a difference between msbuild engine interpreting your projects and Visual Studio showing settings for the project. In some cases you might find that after refactoring .vcxproj files some standard project configuration dialogs not showing information you configured in .props file. To alleviate this, make sure that your <Import> command for .props file is always able to locate the .props file, by setting absolute path to .props file. Second, ensure you specify Label attribute for the <PropertyGroup> element in your configuration file like it was specified in your .vcxproj file.
Finally, make sure your <Import> element is in the right place. Usually you want it to be the very first Import, before you import standard .targets and .props, like Microsoft.Cpp.defaults.props, etc. The reason is msbuild works by performing sequential scans through the statements, so order of instructions matter.
To make #3 and #4 easier, here is a trick to specify absolute path to the .props file. Assume that your solution name is MySolution.sln and custom props file is MyCustomProps.props, placed in the same directory where solution is:
<PropertyGroup>
<RootFolder>$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory),MySolution.sln))</RootFolder>
</PropertyGroup>
<Import Project="$(RootFolder)\MyCustomProps.props" />
We're using Jon Skeet's proto-csharp-port, and I'm running into some difficulties when mixing it with ReSharper in Visual Studio 2010.
We generate the .cs files via a custom MSBuild target, hooked up as follows:
<Target Name="BeforeBuild" DependsOnTargets="CompileProtos" />
The CompileProtos target runs ProtoGen and then adds the generated .cs files to the #(Compile) item group, by using CreateItem. This looks in a defined directory and compiles every .proto file it finds, so they're not listed in the project.
Where it falls down is that ReSharper doesn't recognise the content of the .cs files (because they're not in the project and might not exist yet), so I can't get the solution analysis light to go green.
If I add the .cs files to the project, then I get a build failure, because the .cs file has been added to the Compile item group twice.
I know that Marc's protobuf-net has Visual Studio 2008 goodness in it, and I'm looking for something similar, but for Jon's protobuf-csharp-port and for Visual Studio 2010.
Ideally, I'd like to be able to add the .proto files to the project, have them built correctly, and have Visual Studio and ReSharper know about the generated .cs files, so that IntelliSense and solution analysis work properly.
I'm guessing that something like how .xsd files can implicitly generate .cs files would do the trick.
I've attempted to get this working by implementing a custom tool for code generation, but I've run into a seemingly insurmountable hurdle:
protoc takes a directory full of .proto files and generates a .protobin file. This is then fed to ProtoGen which spits out a .cs file for each protocol definition. Unfortunately, it appears that the .protobin file needs to contain all of the definitions, otherwise you get Error: Unable to resolve all dependencies.
Since the custom tool model in Visual Studio assumes a single input file and a single output file (i.e. foo.proto -> foo.cs), it doesn't look like this can be made to work.
At least, not without finding some way to include all of foo.proto's imported .proto files in foo.protobin, anyway.
I solved it by removing the CreateItem from the CompileProtos target, and by defining it as a proper ItemGroup:
<ItemGroup>
<Protocols Include="$(ProtocolsPath)\*.proto"/>
</ItemGroup>
<ItemGroup>
<Compile Include="#(Protocols -> '%(Filename).cs')"/>
</ItemGroup>
This means that Visual Studio (and ReSharper) pick up the .cs files correctly, once they've been built, and ReSharper's full solution analysis stops complaining.
Unfortunately, Visual Studio has a habit of expanding the ItemGroup into individual Compile entries, but I can check for that before checking anything in.