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.
Related
I'm working on a project where I generate C# classes in a pre-build step using XSLT and XML to generate those. Those generated classes are included in one file, let's name it "MyClasses.cs" file. The problem now is, if a developer removes the file from the solution after the build is done and try to build the solution again, I see ItemGroup added like that under the project file as follows:
<ItemGroup>
<Compile Remove="MyClasses.cs" />
</ItemGroup>
While this won't prevent the generation of the classes again, it causes the solution to not build because the generated classes won't be included in the project. Meaning, the file needs a developer to include manually (right click and include it) so the entire solution can build. So, I wanna do is prevent people to remove the generated code "MyClasses.cs" file so that they can always build or override the behavior of Visual Studio to add an ItemGroup with Remove action for that file when removing it. Is that possible?
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
This question already has answers here:
How to upgrade csproj files with VS2017
(6 answers)
Closed 3 years ago.
I have two projects in VS2015
One .NET Core (project.json, xproj)
One regular .NET csproj
When I open project 1 with VS2017, it nicely migrates to the new csproj format.
Project 2 works in VS2017, but I like to convert/migrate/update this csproj to the new project file format to benefit from the new csproj features (multi target, no large file list, readable csproj, NuSpec info in csproj etc)
How could I do that? I cannot find an option in VS2017 for that.
Using: VS2017 RTM
It may be worth your time to look at these. It looks like it can't be done for more complex project types but console and libraries appear to be upgradable
http://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/
https://github.com/NickCraver/PerfBenchmarks/commit/53c3013b1774056363dcab867bceb1b89ce9592c
And regarding the addition of the more complex sdk types you can watch this github issue.
https://github.com/dotnet/sdk/issues/491
There isn't an option built into VS because the cleaner csproj is primarily for .NET Core projects. It does not fully work with all other project types without some effort and futher customizations in the project file. For example, wiring up things like code generators or nesting in Winforms or WPF apps may not work out of the box for a new SDK-style (new style) .csproj. These can usually be worked around by updating metadata as needed:
<ItemGroup>
<Compile Update="Properties\Resources.Designer.cs">
<AutoGen>True</AutoGen>
<DependentUpon>Resources.resx</DependentUpon>
</Compile>
</ItemGroup>
Note that the Update attribute is key here - you don't want to include the file a second time in the ItemGroup, you just want to update its existing (or lacking) metadata.
There are also some caveats for some project types where targets do not get imported as expected in an SDK-based csproj vs and old one. This depends on how your targets are authored, but one example of this is building VSIX projects (VS extensions) using the VSSDK is really hard to get right in an SDK-based project.
If you want to try the conversion, Nate McMaster's blog post is an excellent resource. He covers both starting from scratch and converting the file in situ. I've found that most of the time it goes pretty smoothly to start with a new clean .csproj and add in any workaround needed.
It's also worth pointing out that a lot of the crap in your normal csproj file is just generated content, and a little hand-editing can go a long way towards cleaning it up. Using globbing patterns, for example, can save hundreds of lines in a large project file. This is part of how SDK-based projects work anyways - they just do the globs in the SDK, so it doesn't show up in the .csproj, but it works nearly the same. For example, if you want to include all the C# files under a folder (recursively), you can do something like this:
<ItemGroup>
<!-- Include all C# files under the SampleFolder and any child folders -->
<Compile Include="SampleFolder\**\*.cs" />
<!-- Include all C# files under this project's root: -->
<Compile Include="**\*.cs" />
<ItemGroup>
The ** matches any recursive folder path.
There are some differences in Visual Studio behavior, because the new project system for SDK-based projects works very different than the old .csproj project system. For example, SDK-projects will automatically detect when files change on disk and add/remove them in the projects; old-csproj won't update them in VS until the project is reloaded.
If you do use globbing everywhere, you'll run into a similar problem as in SDK-based csproj, where certain files are not hooked up to their code generators or nested correctly. As above, you can use the Update= attribute to fix up specific files (or even more specific globs) to get the metadata back to the same.
I have an F# solution in Visual Studio 2015 (Enterprise) with several projects in which control various pieces of hardware. In each project there are .fsx script files which demonstrate how the API is used to do basic tasks on the hardware. If I make changes to the API and rebuild, then I correctly get the Error List populated with all the errors from the compiled .fs files, but since the .fsx aren't required to make the .dlls, then I don't get errors from them when I change the underlying API.
If I open each .fsx file individually in the editor, then I get the Error List populated for as long as the file is open, but I'd like to have them block the build and all appear, rather than having to go through each in turn, which takes quite a while. Is there any way to do this?
Thanks in advance.
The suggestion from Fyodor would certainly work - but I guess building a custom step for the build system might not be the easiest thing to do!
A simple alternative would be to add a separate F# project that contains the fsx files and compiles them - then you can just ignore the result of the building the project.
When you add fsx file to project, it is not compiled as part of the project build, but you can change that by choosing Compile as an "Action" in the properties window in Visual Studio. Alternatively, you can just edit the fsproj file:
<Compile Include="some.fsx" />
When editing the file by hand, you can also make it point into another folder:
<Compile Include="..\OtherProject\some.fsx" />
I've added a new build target to my C++ Visual Studio project (vcxproj).
This target runs a custom tool when the project is built. The tool processes specific files on the solution according to the ContentType and ItemType I specified.
This works well with project actions such as "Build" and "Clean".
Now I would like to support an action equivalent to "compile", i.e. right click on a file in the Solution Explorer and select to process this specific file with my custom tool (the same way "compile" runs "CL" for "C/C++ Code" file types).
I know I could add a Visual Studio macro to do this. This is not a good solution for me because it's harder to deploy for many users.
A better solution is to customize the vcxproj (or files imported by it).
I wonder if it's possible to add a "compile" like action in the menu (or change the "compile" behavior for file types other than "C/C++ Code") through msbuild targets scripts or PropertyPageSchema.
UPDATE: I've started a discussion on MSDN forum. Got some answers from a Microsoft moderator that helped clearing up some things, but the problem is still unsolved.
UPDATE (2016), for VS2015
AvailableItemName seems to solve this on VS2015. For example, I have a custom target to process Excel files.
On the targets file:
<ItemGroup>
<PropertyPageSchema Include="$(SolutionDir)\ExcelOptions.xml" />
</ItemGroup>
<ItemGroup>
<AvailableItemName Include="Excel">
<Targets>ProcessExcel</Targets>
</AvailableItemName>
</ItemGroup>
On the options file:
<FileExtension Name=".xls" ContentType="Excel"/>
<ContentType Name="Excel" DisplayName="Excel File" ItemType="Excel"/>
<ItemType Name="Excel" DisplayName="Excel File"/>
Now Compile is accessible on the Solution Explorer context menu after selecting an excel file, and CTRL-F7 works as well (for files that can be edited on VS, not for excel files)