$(ProjectName) and $(TargetName) MSBuild macros not working - c#

I am using Visual Stduio 2015 Community Edition. I have loaded a C# project and want to configure it to use shadow building, so that source files are not messed up with any binaries or intermediate build files. Tried to set the [output]/[intermediate output] directory paths of the C# project using the VS UI - the only UI-editable output path is the "bin" one and it doesn't accept MSBuild macros. Then I've unloaded the project and manually edited it. Also set the IntermediateOutputPath which is not available in the VS UI when using C# project, but when using C++ one all such kind of directories are editable.
Currently, the OutputPath is set to:
<OutputPath>$(SolutionDir)..\build_$(SolutionName)_$(Configuration)_$(Platform)\$(ProjectName)</OutputPath>
$(ProjectName) is empty for some reason. Tried $(TargetName) (it is not correct to use it but just for the test) but it is empty, too. Any suggestions?

Do not try to import Microsoft.CSharp.targets - like suggested in another answer.
First of all - it will lead to additional warning like
Warning MSB4011: "Microsoft.CSharp.targets" cannot be imported again. ...
But additionally to that if you try to edit pre-/post- build Visual studio will crash.
(Observed in Visual studio 2019, 16.7.7 version)
Better to use $(MSBuildProjectName) macro instead of $(ProjectName) - works identically.

The problem is that some of the MSBuild properties like ProjectName are set after the following line in your .csproj file.
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
After this line you can access all variables.

Related

How do I set `OutputPath` in a Visual Studio 2017 project (new .csproj file format) without the target framework cluttering the resolved path?

Setting OutputPath in the new Visual Studio 2017 project format automatically adds the target framework in the path. For example, if I have these set in the project file:
<TargetFramework>net462</TargetFramework>
<OutputPath>/build/debug/<OutputPath>
The actual output folder will resolve to /build/debug/net462/, not /build/debug/ like in the older versions.
How do I solve this without workarounds like moving things around with post build actions?
The solution is to use AppendTargetFrameworkToOutputPath https://www.tabsoverspaces.com/233608-stopping-msbuild-appending-targetframework-to-outputpath/
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
The answer above is right, but you may also want to remove the runtime identifier:
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>

External msproject, imported in CMake, would not build

I have a CMake-based C++ project, and recently I've included existing C# program into it.
Here is CMake code:
include_external_msproject(MarkTrainingSet MarkTrainingSet.csproj
GUID 77A5B8C9-998E-4D0E-A444-6AD14FB0DC37
PLATFORM AnyCPU)
The .csproj file was generated by the same Visual Studio 2013, as builds my C++ project. GUID value and AnyCPU platform are the values from that file.
My problem is that this C# project is not built when I issue Build solution command to the Visual Studio.
I have to go to the solution properties (right-click on the solution in Solution Explorer), then Configuration Properties -> Configuration, and manually check Build checkbox in the line, corresponding to my MarkTrainingSet project.
If CMake regenerates the solution, I have to recall about that checkbox and redo the procedure.
The documentation about include_external_msproject is very incomplete.
What should I do to make this C# project always build automatically?
The last time I looked, CMake's implememtation of include_external_msproject() is restricted to C/C++ projects.
You may find this defect report worth a look, though it looks stale. http://www.cmake.org/Bug/view.php?id=9742 ... ( also see http://marc.info/?l=cmake&m=133319401303885 )
I couldn't get a sense of whether the patches were included in CMake or not though, but the defect is still open.
Generally syntax looks like this:
include_external_msproject(projectname folder/projectname.csproj PLATFORM AnyCPU)
Seems to work with vs2019 included cmake.

Visual Studio ignores my syntax errors in ASP.net project

I migrated a visual studio solution from using a "website" to a "ASP.net project" to be able to use Web.config transformation.
Now, after having migrated, Visual Studio completely ignores syntax erros when I clean/build/rebuild my solution.
Those syntax errors will be shown in my browser as soon as I open the web application - but seeing them during compile time would be helpful. They used to be shown in my error list - where I can now only see some uninteresting warnings.
I can still run my web application, and everything works well.
How can I configure my solution, so that compile errors will appear during compile time?
edit (in response to answers/comments):
As soon as I open the .cs file (by double clicking on it) the syntax errors are shown (inside the file and inside the error list view).
I'm using Microsoft Visual Studio Professional 2012 (Version 11.0.61030.00 Update 4) with .NET 4.5.50709 (german language version). I'm locally deploying to Visual Studio's IIS.
I'm not using NuGet, all my sources are in one single project
I'm actually only providing a REST-Backend using WCF. I only have c# sources. The syntax errors are in my c# classes.
The syntax errors are in my .cs files in my App_Code folder.
When I migrated my website to a project I manually edited my .csproj file (added missing "Content Include"s etc.). I hope that this did not break my solution...
I am not using the default "DEBUG" and "RELEASE" build configurations, but created my own server-specific configurations (named after the names of each server).
( #Guvante ) When I edit the build configurations, I see one line in the "project context table". The first and only line shows:
the name of my project
the configuration name in a dropdown
the plattform "Any CPU"
a checked checkmark "build"
the empty field "deploy"
My error list is filtered to "current project" and it won't show the syntax errors, no matter which item I select in my solution explorer.
Sometimes (can't tell when exactly) VS shows a warning, when starting debugging, telling my that my module was build with optimizations or without debugging information. Don't know, whether this warning is related to this issue.
Console output of successful build (though sources contain syntax error) is:
1>------ Erstellen gestartet: Projekt: MyProject, Konfiguration: localdev Any CPU ------
1> MyProject -> C:\path\MyProject\bin\MyProject.dll
========== Erstellen: 1 erfolgreich, 0 fehlerhaft, 0 aktuell, 0 übersprungen ==========
I saved, closed VS, rebooted machine, reopened VS, closed eyes, crossed fingers - #chief-two-pencils ;)
In the .csproj file you can change
<Content Include="C:\...\foo.cs" />
back to
<Compile Include="C:\...\foo.cs" />
More info on the MSDN documentation and this stackoverflow question.
You should change it to:
<Compile Include="....." />
The MSDN article on the build action property says:
Compile - The file is compiled into the build output. This setting is used for code files.
Content - The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file. Means that it is a deployable project item, it signals that the file needs to be copied to the target machine. Also note that Content will be included when using one-click deploy.
See more about build action here.
if you have Nuget packages run an update-package
try to unload the project and reload it into the solution
This worked for me

How to find the reason for a failed Build without any error or warning

I have a WebApplication which contains reference to WCF services.
While building using Visual Studio 2010, Build fails without any error or warning. However building the .csproj using MsBuild is successful.
Can't figure out what should I try in Visual Studio, to resolve / diagnose the issue. Can you please help out?
I find out that the build has been failing,
From text displayed in status Bar.
From output window:
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
The output tab includes configuration details.
------ Build started: Project: <projectName here> Configuration: Debug Any CPU
I noticed that if "Build + Intellisense" is selected in the Error List, it causes the error messages to be swallowed.
Change this option to "Build Only", and all error messages will be displayed:
I don't know if this is a bug in Visual Studio or what, but it certainly revealed hidden error messages that were the key to pinpointing the failure for me.
Some, like Richard J Foster, have suggested increasing the "MSBuild project build output verbosity" setting to "Diagnostic" (the highest possible option), but this didn't solve the problem for me, as Visual Studio appeared to be suppressing the error message(s) themselves.
As an alternative, you may try to use the raw output messages from the "Output" tab, which haven't been filtered by Visual Studio. Either do an in-place search for the strings "error" and/or "failed", or copy all of the output to your favorite text editor and do a search there.
To ensure that the Output window appears each time you do a build, you can go to Tools → Options → Projects and Solutions → General, and ensure that the option "Show Output Window when build starts" is checked.
As an additional troubleshooting step, it is also possible to build the project from the PowerShell command line by running dotnet build. This will show you the complete build output, including any errors that Visual Studio may be hiding.
I just ran into a similar situation. In my case, a custom action (from the MSBuildVersioning package available on Nuget.org - http://www.nuget.org/packages/MSBuildVersioning/) which appeared in the csproj file's BeforeBuild target was failing without triggering any error message in the normal place.
I was able to determine this by setting the "MSBuild project build output verbosity" (in the latest Visual Studio's Tools tab [Path: Tools > Options > Build and Run]) to "Diagnostic" as shown below. This then showed that the custom action (in my case HgVersionFile) was what had failed.
Here are some things that you can try:
If your solution contains more than one project, try building each project one at a time. (You may even want to try opening each project independently of the solution.)
If applicable, ensure that all of your projects (including dependencies and tests) target the same version of the .NET Framework. (Thanks to user764754 for this suggestion!)
Tip: Check Tools → Extension and Updates to ensure that your packages are up-to-date.
Ensure that all dependency projects are built to target the same platform as your main project.
Try restarting Visual Studio.
As suggested by Bill Yang, try running Visual Studio as Administrator, if you aren't already. (If you are already running Visual Studio as Administrator, perhaps try the opposite?)
Try restarting your computer.
Try "Rebuild All".
Run "Clean Solution", then remove your *vspscc* and *vssscc* files, restart Visual Studio, and then "Rebuild All".
As suggested by Andy, close Visual Studio, delete the .suo file, and restart Visual Studio.
As suggested by Arun Prasad E S, close Visual Studio, delete the .vs folder in your solution directory, and then re-open Visual Studio. (This folder is auto-generated by Visual Studio and contains cache, configuration settings, and more. More details can be found in these questions: Visual Studio - Deleting .vs folder and https://stackoverflow.com/q/48897191.)
As suggested by MrMalith, close Visual Studio, delete the obj folder in your solution directory, clear your temporary folder, and then re-open Visual Studio.
Delete the hidden .vs folder & restart Visual Studio. That worked for me.
I want to expand on Sasse's answer. I had to target the correct version of .NET to resolve the problem.
One project was giving me an error:
"The type or namespace name 'SomeNamespace' does not exist in the namespace 'BeforeSomeNamespace' (are you missing an assembly reference?)".
There was no error in the Error List window but the assembly had a yellow warning sign under "References".
I then saw that the referencing project targeted 4.5.1 and the referenced project 4.6.1. Changing 4.6.1 to 4.5.1 allowed the overall build to succeed.
Nothing was working for me so I deleted the .suo file, restarted VS, cleaned the projected, and then the build would work.
I tried many things like restarting Visual Studio, cleaning and rebuilding the solution, restarting the PC, etc., but none of them worked for me. I was finally able to solve the problem by doing the following:
First of all, make sure all the projects in your solution (including tests) are targeting the same .NET version. Then:
Save pending changes in the project and close Visual Studio
Find the exact location from file explorer and find "obj" file and open it,
Then, delete all the included files (some files won't remove, it doesn't matter, just skip them).
Use run command (by pressing Windows Key + R) and type "%temp%" and press enter to find temporary files.
Finally, delete them all.
On other possibility is that Visual Studio needs to run as Administrator, this might be related to deploying to local IIS server or other deployment need.
Just for the sake of completion and maybe helping someone encountering the same error again in the future, I was using Mahapps metro interface and changed the XAML of one window, but forgot to change the partial class in the code-behind. In that case, the build failed without an error or warning, and I was able to find it out by increasing the verbosity of the output from the settings:
In my case (VS 2019 v16.11.20), disabling Text Editor->C#->Advanced->Enable 'pull' diagnostics in the options solved the issue.
Double check for _underscore.aspx pages in your project.
I had a page and code-behind:
`myPage.aspx` and `myPage.aspx.vb`
when building the project, I'd get errors on the .aspx.vb page stating that properties defined on the .aspx page didn't exist, even though the page itself would build fine and there were NO OTHER ERRORS showing in the output (even with diagnostic level build output).
I then came across a page in the project that was named the same thing but with an underscore: _myPage.aspx - not sure where it came from, I deleted it, and the solution built fine.

Using an external tool for C# builds in Visual Studio

When using Visual Stdio 2008, you can make a C++ project build with an internal tool rather than having the IDE invoke MSVC directly. This improves the consistency of builds across platforms if a cross-platform build system is used.
However, I cannot figure out how to do the same as a C# project. It would be possible to simply register it as a native project with C# sources, however, you lose some of the advantages gained through having a C# project. More importantly, it will mean that allowing a project to build both directly and with an external tool (which is sadly necessary) will require two separate projects, rather than merely creating an alternate build configuration to invoke the external tool.
Does anyone know if it's possible to prevent Visual Studio from invoking csc by itself and instead call an external tool?
EDIT: Apparently there has some misunderstanding. The goal here is not to compile anything outside of Visual Studio. Instead, it's to allow Visual Studio to serve as the IDE but not the build system. There is already a (Scons-based) build system capable of compiling the C# and C++ sources, and Visual Studio has been configured to invoke Scons for compilation of C++ projects. I'm trying to configure it so that when you hit the 'Build' button, it will invoke Scons for the C# projects as well as the C++ ones.
Edit: Your question is still answered using MSBuild(if you are simply looking to compile outside the IDE). The IDE(Visual Studios) is simply a "fancy" way of constructing the build files that are built by MSBuild. Visual Studios isn't building the files, it simply is invoking MSBuild which ships with the .NET Framework 2.0 and up which compiles your code based on the project file that you create. If Scons can read and process an MSBuild file then I'm sure you can invoke it to build your project. But considering the fact that C# is a Microsoft language, I think you will be hard-pressed to find a value-add in not using MSBuild since I'd assume both the language and build tool are very tuned to work together. - End Edit
You can use MSBuild to compile your C# project. If you open your .csproj file in a text editor you will see that it is a MSBuild file. If you want to write some C# outside of the IDE you can construct a build file using the .csproj file as a starting point and invoke MSBuild to compile your apps. The IDE is just a way of abstracting the editing of the MSBuild file away for you.
If you are really industrious you can create a set of custom tasks to do things in your custom build process like move files around and versioning. MSBuild Community Tasks are a great example of using custom code to do task for you during MSBuild.
Given all the other answers, what MSBuild does when either VS or MSBuild perform a build can be found in the Targets files that ship with .Net. These can be be found in the FrameWork directory on your system. In my case:
C:\Windows\Microsoft.NET\Framework64\v3.5
Contains Microsoft.Common.targets among others. This file contains the following snippit:
<!--
============================================================
Build
The main build entry point.
============================================================
-->
<PropertyGroup>
<BuildDependsOn>
BeforeBuild;
CoreBuild;
AfterBuild
</BuildDependsOn>
</PropertyGroup>
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(BuildDependsOn)"
Outputs="$(TargetPath)"/>
This means that redifining this Target you can make MSBuild an VS do anything you want. The top of the mentioned file contains an important messagge:
Microsoft.Common.targets
WARNING: DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
created a backup copy. Incorrect changes to this file will make it
impossible to load or build your projects from the command-line or the IDE.
This file defines the steps in the standard build process for .NET projects. It
contains all the steps that are common among the different .NET languages, such as
Visual Basic, C#, and Visual J#.
My suggestion would be to read all you can about MSBuild and it's build file syntax and try redifining the Build target in your project(s). My impression is that after reading up on MSBuild you'll probably find an easier way to meet your requierements. You can find an example of redifining a Target like this in one of the answers of this so question .
Edit:
How to redefine a target?
Redefining is essentially defining the same target 'after' it has been defined. So for instance in your .*proj file(s) define a Build Task after the <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> line that imports all targets needed to in this case build a C# project. An example could be
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="BeforeBuild"
Outputs="$(TargetPath)">
<Exec Command="nmake" />
</Target>
I found a question in the same direction here, where it is suggested to edit the registry. I am pretty sure there is no other way to change the compiler used by Visual Studio because there is no trace of csc.exe in any solution, config, csproj file or whatsoever, nor in the Visual Studio 9.0 folder / subfolders within the Program Files dir.
Registry locations can be found in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\74ACAA9F1F0087E4882A06A5E18D7D32
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\9055DA7481CC1024CB23A6109FD8FC9B
but those keys may differ dependng on your installation. Conclusion: changing the compiler used by VS seems next to impossible.
Addition: The following MSDN article deals with the same question for an custom C++ compiler, and Ed Dore's answer seems to confirm my theory that there's no way to choose an custom compiler for use within VS.
Under 'Tools' > 'External Tools' you should be able to define an outside tool to do activities for you. The Command should be the path to the executible for your external tool.
Hope this helps some.
You don't have to maintain different project files to build using an external tool. MSBuild is designed to build using the same project files that Visual Studio uses.
Here's an article that describes it.
Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool
It's for VS2005, but should apply to VS2008 as well.
Looking through the answers, it seems clear to me that integrating scons into Visual Studio in a way that is compatible with the debugger and so on is not going to happen...
An option you might to consider, and I understand you don't want to change build systems, but bear with me, is to use a meta-build system, ie 'cmake'. http://www.cmake.org/
Cmake doeesn't actually build the project. What it does is to create build files for you, that you can use to build the project, and on Windows, the build files it creates for you are: Visual Studio project files. You can simply load those directly into your IDE, and compile, and use normally!
CMake is I feel very easy to use, and provides a high level of transparence and maintainability.
The exact same CMakeLists.txt files on linux will causes linux makefiles to be generated.
On mingw, they can generate mingw makefiles.
There are numerous generators available within cmake. The list is here:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Generators
http://springrts.com is a huge opensource rts game that used to use scons as its cross-platform build system and now uses cmake.
I understand that you don't really want to have to change build systems, so it is a medium to long term solution.
Cmake is in any case one more option, to add to those of using a custom build tool, or using msbuild, or running the scons build from the commandline by hand.
Edit your project file and update the CscToolPath keys to point to the directory containing your tool and add CscToolExe keys that holds the name of the directory:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|.NET 3.5' ">
.
.
.
<CscToolPath>path\to\custom\tool\directory</CscToolPath>
<CscToolExe>exe name</CscToolExe>
.
.
.
</PropertyGroup>
I have not tested this, and the CscToolExe key may cause problems, in which case I would simply rename the external tool executable to "csc.exe".
You can build your solution from the command line like this:
C:\WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe "C:\path\Your Solution.sln"

Categories

Resources