I have been working with a DLL which contains some classes, and one of the classes has some constants. I wrote Summary for every one of these constants and these summaries appears as "tooltips" when I want to use the constants inside the DLL.
However, when I access these constants from the main project which is referencing this DLL, I don't see any Summary in the tooltip.
Does anyone know a solution for this problem? Everything is declared with a public access modifier. But MVS2013 does not cache these Summaries.
To see the summaries outside of the project you need to build the XML documentation file. Go to the project settings and select the Build section. At the bottom you'll see the "Output" options, and there will be a checkbox for XML documentation file make sure it's checked (in both debug and release modes).
If you're deploying the assembly by hand to other projects you'll need to make sure you copy the documentation XML file as well.
I'm trying to parse a group of vcxproj files and am running into difficulties with their use of macros in properties.
A trivial example is
<ProgramDatabaseFile>$(OutDir)$(ProjectName).pdb</ProgramDatabaseFile>
$(Outdir) and $(ProjectName) are generally relatively easy to infer from the file, although this particular one has quite a few different configurations.
I was wondering, rather than reinventing the wheel (again), is there a utility or library (preferably C#) which will derive from a project file all of its macros and their associated values?
Obviously msBuild and Visual Studio are able to extract this information, so it seems like they might share some library or program to do it.
It looks like the
Microsoft.Build.Evaluation.Project
class has what I need in it's Properties field
When I create C# project in Visual Studio 2010, file Microsoft.CSharp.targets is included.
Is any documentation available for it?
Which targets in it, which properties are used?
It is especially useful when editing build script manually without VS.
The file with targets could be investigated manually (what I do from time to time).
But in such case it is not clear what is a matter of changes, what is by specification and what is no.
Everytime I need something about Microsoft.CSharp.targets I found it in different places.
I have not found "one place" with all described.
Does complete reference available?
Thanks.
No specific documentation I know of, it is an implementation detail for C# projects. You can find plenty of documentation about MSBuild in the MSDN library, the Microsoft.CSharp.targets file just contains targets that are specific to building a C# project.
The most important targets it implements are Build, Clean and Rebuild. They directly correspond to the commands you find in the VS build menu. The .csproj file merely sets properties that affect the outcome of the general targets. All of this is readily available on your machine, you can look at .targets files with an editor. There's just a whole lot of it and it is isn't exactly that easy to read, the concept of XML as a programming language is a bit, well, flawed. No debugger either.
I'm trying to generate a C# project within an existing C++ CMake code base on Windows. After some research, I could find only two projects that built their own CSharp compilers for CMake:
gdcm and kde.
I tried both of them. Unfortunately, the first one failed to generate a C# project. Instead it created a VS C++ project with cs files in it, and because of C++ flags set for linker, the build always failed with errors. After experimenting with the sample project they provided, I wonder whether this could be due to a limitation of the "Visual Studio 8 2005" code generator?
The second project was primarily aimed at Mono, so I wasn't successful with it either.
Has anyone had a positive experience with building C# projects using one of those CMake modules or something else?
As of CMake 3.8.2, CSharp project generation is officially supported by CMake.
To build the default Visual Studio 2017 generated C#/WPF project using CMake, create a CMakeList.txt file as follows.
Project Declaration
project(Example VERSION 0.1.0 LANGUAGES CSharp)
Include CMake CSharpUtilities if you are planning on using WPF or other designer properties.
include(CSharpUtilities)
Add all cs, xaml, settings, properties
add_executable(Example
App.config
App.xaml
App.xaml.cs
MainWindow.xaml
MainWindow.xaml.cs
Properties/AssemblyInfo.cs
Properties/Resources.Designer.cs
Properties/Resources.resx
Properties/Settings.Designer.cs
Properties/Settings.settings)
Link designer files, xaml files, and other properties files with their corresponding cs files
csharp_set_designer_cs_properties(
Properties/AssemblyInfo.cs
Properties/Resources.Designer.cs
Properties/Resources.resx
Properties/Settings.Designer.cs
Properties/Settings.settings)
csharp_set_xaml_cs_properties(
App.xaml
App.xaml.cs
MainWindow.xaml
MainWindow.xaml.cs)
Set app App.xaml properties file as program entry point (if project is a WPF project)
set_property(SOURCE App.xaml PROPERTY VS_XAML_TYPE "ApplicationDefinition")
Set other csproj file flags
set_property(TARGET Example PROPERTY VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.6.1")
set_property(TARGET Example PROPERTY WIN32_EXECUTABLE TRUE)
// ...
Add libraries
set_property(TARGET Example PROPERTY VS_DOTNET_REFERENCES
"Microsoft.CSharp"
"PresentationCore"
"PresentationFramework"
"System"
"System.Core"
"System.Data"
"System.Data.DataSetExtensions"
"System.Net.Http"
"System.Xaml"
"System.Xml"
"System.Xml.Linq"
"WindowsBase")
For a working WPF example, see https://github.com/bemehiser/cmake_csharp_example
For a WinForms example, see this answer.
CMake 2.8.9 and up add a TYPE parameter to include_external_msproject like so:
include_external_msproject(
MyProject MyProject.csproj
TYPE FAE04EC0-301F-11D3-BF4B-00C04F79EFBC)
This lets you specify that the project is C# (the magic GUID above), otherwise things struggle (see docs).
You will probably still want to use the configure_file template approach mentioned elsewhere with your .csproj file to get the right paths into it, unless you're building straight into your source tree.
The good news is that you can wildcard your C# files in the .csproj.template file like so:
<ItemGroup>
<Compile Include="${DOS_STYLE_SOURCE_DIR}\**\*.cs" />
</ItemGroup>
And you'll need something like this in your CMakeLists.txt to convert CMake's unix-style forwardslash path separators into Windows-style backslashes, otherwise it will compile the files but they won't show up as links in the project in Visual Studio:
FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_SOURCE_DIR}" DOS_STYLE_SOURCE_DIR)
Then it's just:
CONFIGURE_FILE(MyProject.csproj.template MyProject.csproj)
In your CMakeLists.txt to configure the template file into a real project file with the right wildcard path.
HTH.
Just in case anyone is still looking for information about this, there is really no reason to generate C# projects with CMake, they are cross platform by design. On Linux, C# projects are generally managed with MonoDevelop which can read .csproj files from visual studio just fine. This should enable cross-platform development of C# projects.
The only potential issue would be if you had native c++ projects mixed with c# projects (like a backend written in c++ with a GUI in c#), in this case just have cmake copy over your .csproj files as though they were data and you should be good to go.
CMake is intended to set up your build environment to be cross platform. This comes in really handy with c++ where code is built in a very different way on linux than on windows (or other OSs if youre into that), but is kind of unnecessary for c# which can execute cross-platform, and, thanks to design decisions by the mono team, can build cross platform. CMake does provide some great tools to automate things, but much of this functionality can be recovered with a properly configured .csproj file.
Anyway I know this question is over a year old but it's one of the top search results I stumbled on when I was looking up how to do this. I've since made this realization.
To piggy-back on the answer provided by #the_storyteller, CMake v3.8 and greater indeed supports C# as a first-class language. Because a WPF example was already provided, here is a complete CMake example for a simple Windows Forms application. I've provided the optional commands for linking in other libraries built locally in the source tree, and linking 3rd party library dependencies.
Note that Windows Forms applications require the use of the csharp_set_windows_forms_properties CMake command, whereas WPF projects use csharp_set_designer_cs_properties and csharp_set_xaml_cs_properties.
CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(MyWinFormApp LANGUAGES CSharp)
# Include CMake utilities for CSharp, for WinForm and WPF application support.
include(CSharpUtilities)
# Define the executable, including any .cs files.
# The .resx and other Properties files are optional here, but including them makes them visible in the VS solution for easy editing.
add_executable(MyWinFormApp
App.config
Form1.cs
Form1.Designer.cs
Form1.resx
Program.cs
Properties/AssemblyInfo.cs
Properties/Resources.Designer.cs
Properties/Resources.resx
Properties/Settings.Designer.cs
Properties/Settings.settings
)
# Set the .NET Framework version for the executable.
set_property(TARGET MyWinFormApp PROPERTY VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.6.1")
# Set the executable to be 32-bit.
set_property(TARGET MyWinFormApp PROPERTY WIN32_EXECUTABLE TRUE)
# Set the C# language version (defaults to 3.0).
set(CMAKE_CSharp_FLAGS "/langversion:latest")
# Set the source file properties for Windows Forms use.
csharp_set_windows_forms_properties(
Form1.cs
Form1.Designer.cs
Form1.resx
Program.cs
Properties/AssemblyInfo.cs
Properties/Resources.Designer.cs
Properties/Resources.resx
Properties/Settings.Designer.cs
Properties/Settings.settings
)
# If necessary, link in other library dependencies that were built locally in this source tree.
target_link_libraries(MyWinFormApp MyLocalLib)
# If necessary, link in other library/DLL references, such as 3rd party libraries.
set_property(TARGET MyWinFormApp PROPERTY
VS_DOTNET_REFERENCE_MyThirdPartyLib /path/to/libs/MyThirdPartyLib.dll)
# Add in the .NET reference libraries.
set_property(TARGET MyWinFormApp PROPERTY VS_DOTNET_REFERENCES
"Microsoft.CSharp"
"System"
"System.Core"
"System.Data"
"System.Drawing"
"System.Windows.Forms"
)
I was finally able to generate a valid solution using the second c# module - kde.
Although, cmake created a number of .vcproj files while I expected to get .csproj, but I guess that is the only form "Visual Studio 8 2005" generator can offer.
Nevertheless I was able to successfully build this solution and produce executables and dll libraries.
You can create a project with Visual Studio, than take it apart and make CMake write it using configure_file command (you'll have to generate a bit of XML with the list of sources) and add it to the solution with include_external_msproject (for other generators you'll need to create the custom target to run msbuild on it manually; cmake does not seem to support doing that yet). The project is rather simple, so it should be possible to do that.
I wanted to point out that it is now possible to generate C# Projects using the SDK-Style project XML format using CMake 3.23.
Although it is still a release candidate version, it works pretty well with CMake 3.23 rc2. To create C# SDK-style projects use DOTNET_SDK target property.
For example one could use C# SDK-style project with this line
set_target_properties(myTarget PROPERTIES DOTNET_SDK "Microsoft.NET.Sdk")
Also remember that you don't need a project() command when creating C# Projects with CMake. The project() command always creates a new solution which could be useful but not necessary. One can use enable_language(CSharp) to declare a Target being a C# Project.
To test C# SDK-style projects I used Visual Studio 2019 with Visual Studio 16 Generator on Windows.
I have a solution that contains several c# projects and I would like to be able to set the output path and other properties on all the projects together in a single place. Property Sheets (vsprops) do not seem to be able available for C# projects and the $(SolutionDir) variable is ignored. Are there any other methods to set properties across several C# projects?
Update
By Following the information in the answer by Bas Bossink I was able to set the output path of several projects by creating a common csproj and importing it into the individual project. A few other points:
When building in Visual Studio if changes are made to the common project it is necessary to touch/reload any projects that reference it for the changes to be picked up.
Any properties which are also set in a individual project will override the common properties.
Setting $(SolutionDir) as the output path via the Visual Studio UI does not work as expected because the value is treated as a string literal rather than getting expanded. However, Setting $(SolutionDir) directly into the csproj file with a text editor works as expected.
A csproj file is already an msbuild file, this means that csproj files can also use an import element as described here. The import element is
exactly what you require. You could create a Common.proj that contains something like:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5"xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OutputPath>$(SolutionDir)output</OutputPath>
<WarningLevel>4</WarningLevel>
<UseVSHostingProcess>false</UseVSHostingProcess>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
</Project>
You can import this Common.proj in each of your csprojs, for instance like so:
<Import Project="..\Common.proj" />
The import statement should precede any tasks that depend on the properties defined in Common.proj
I hope this helps. I can't confirm your problems with the $(SolutionDir) variable I've used it many times. I do know however that this variable does not get set when you run an msbuild command via the commandline on a specific project that is contained in a solution. It will be set when you build your solution in Visual Studio.
Unfortunately, these bits of information such as output path are all stored inside the individual *.csproj files. If you want to batch-update a whole bunch of those, you'll have to revert to some kind of a text-updating tool or create a script to touch each of those files.
For things like this (apply changes to a bunch of text files at once) I personally use WildEdit by Helios Software - works like a charm and it's reasonably priced.
But I'm sure there are tons of free alternatives out there, too.
I would suggest you to use a build tool such as MSBuild or NAnt which would give you more flexibility on your builds. Basically the idea is to kick off a build using (in most cases) a single configurable build file.
I would personally recommend NAnt.
You could find an awesome tutorial on NAnt on JP Boodhoo's blog here
Set the $(OutputPath) property in a common property sheet. Then delete that entry in all the project files you want to it to affect. Then import that property sheet into all your projects.
For hundreds of projects that can be very tedious. Which is why I wrote a tool to help with this:
https://github.com/chris1248/MsbuildRefactor