MSBuild successful but Visual Studio failed - c#

We're using Jenkins to build out projects using msbuild.
I added a project reference to an existing project but forgot to add these new project to all solution files.
I committed but Jenkins told me that everything works fine.
I tried that on command line:
msbuild test.sln /t:Rebuild /p:Configuration=Debug
Having a totally cleared working directory that works fine, in Jenkins and on my developing machine. The output told me that msbuild found that project and build it.
But if I open Visual Studio 2017 and try to build that solution, it tells me that the depending project could not be found.
That's correct.
How do I force msbuild to only build projects that are specified in the solution file so that we're able to find all solutions that missed that new project?
BTW: We don't need a hint how to find all solutions that need to contain that new project. Finding that solutions is pretty easy.

How do I force msbuild to only build projects that are specified in the solution file so that we're able to find all solutions that missed that new project?
The correct way to avoid MSBuild's default behavior of rebuilding all the dependencies listed in the solution file is to set the BuildProjectReferences property to false, So the build command line should be:
MSBuild Test.sln /t:Rebuild /p:Configuration=Debug /p:BuildProjectReferences=false
After using this command line, MSBuild will get the same error with VS, so we're able to find all solutions that missed that new project
Note: BuildProjectReferences will check all the dependencies listed in the solution file, so please keep his value is true, unless used to check the missing dependencies.
Hope this helps.

Related

MSBuild cannot build a solution when Visual Studio works

I tried to add CI support in my little github repository, so I configured it to use appveyor. But it was unable to build my solution and was failing with odd errors. But it had a build log, so I retyped them in my console and encountered exactly same problem, multiple odd errors like The type or namespace name 'System' could not be found
git clone -q --branch=master https://github.com/Pzixel/RemoteClient.git C:\projects\remoteclient
msbuild "C:\projects\remoteclient\RemoteClient\RemoteClient.sln" /verbosity:minimal
And same here in AppVeyor: https://ci.appveyor.com/project/Pzixel/remoteclient
However VS2017 is just fine with it:
Why does it happening and how could it be fixed?
I think you will need to restore your nuget packages before building your solution. You can download the nuget.exe here.
Than you can run:
nuget restore RemoteClient.sln
msbuild RemoteClient.sln
I did a clean checkout and run both commands.

SpecsFor MVC / MSBuild.exe not building / publishing project correctly in Visual Studio 2012

I am trying to use SpecsFor MVC for automated acceptance testing and I have noticed that it is not building / publishing project correctly on Visual Studio 2012 and hence IIS Express is not running, ending in a 'Page cannot be displayed' message throughout the automated acceptance test.
To take you through all my tests to get this working, initially, when trying to run the automated tests, I was getting a 'Build Failed' message when running
_host = new SpecsForIntegrationHost(config);
_host.Start();
. After loading the SpecsFor MVC source code, I have noticed that the error was because the MSBuild.exe process was failing and the output message was being written to Console.Output. After checking the output, I have noticed that the error was that the Microsoft.WebApplication.targets was not found. After some research, I found the below:
External VS2013 build error "error MSB4019: The imported project <path> was not found"
The one with most votes spoke about removing the <PropertyGroup> node from the .csproj which after removing it, the MSBuild.exe was not exiting with an error code as it only had warnings which still resulted in the project not being built & published correctly. SpecsFor MVC in this case treated this scenario as successful and proceeded with launching IIS Express but since the project was not built successfully, the acceptance tests resulted in another Page Cannot Be Displayed message as IIS Express was not running correctly.
After some further research, I found v11.0\WebApplications\Microsoft.WebApplication.targets was not found when file actually references v10 which outlined that VS 2012 has a new different MSBuild.exe file located in C:\Program Files (x86)\MSBuild\12.0\Bin.
Now the issue is that within the SpecsFor MVC IISTestRunnerAction.PublishSite() method, the path of the MSBuild.exe is being loaded through
System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory() which in my case is outputting C:\Windows\Microsoft.NET\Framework64\v4.0.30319\. Changing this manually to C:\Program Files (x86)\MSBuild\12.0\Bin solved the issue and project was built & published successfully.
My final question is: Is there a way where one can change the value of System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory() so that I wouldn't need to update the source of the SpecsFor MVC project?
Thanks in advance for any help!
As of SpecsFor.Mvc 3.2.0-rc01 (still a preview release as of right now), you can configure the path to MSBuild like so:
var config = new SpecsForMvcConfig();
config.UseIISExpress()
.With(Project.Named("SpecsFor.Mvc.Demo"))
.CleanupPublishedFiles()
//Set the full path to MSBuild.exe here!
.UseMSBuildExecutableAt(#"C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe")
.ApplyWebConfigTransformForConfig("Test");
To understand how these ".targets" files are organized in Visual Studio is a challenge. I don't know nothing about this SpecsFor MVC works, but if you put the right ".targets" file in it's path, it should work. By your question, I understand that SpecsFor invokes MSBuild internally.
It's a similar problem when you install a new build machine, and a lot of Visual Studio componentes are missing. Not all of them are deployed with the framework. Some comes with Visual Studio separated installers other with specific componentes.
I didn't find an specific installer that deploys this needed file. I just found the MSBuild 2012 installer (http://www.microsoft.com/en-us/download/details.aspx?id=40760), and I don't know if it deploys the previous version .targets.
And also you can try the ASP.NET MVC installer for your specific version.
Another approach is try to find a parameter in SpecsFor to see which version of MSBuild it is invoking. Probably if it uses the version in Program Files\v12, it should work.

building error of assemblyInfo.cd could not be found in visual studio 2012 on win 7

After searching the SO forum, I cannot find a working solution for my question. If you find one, I would really appreciate it.
In Visual Studio 2012, I am building a C# project. I get the following error:
Source file 'Properties\Assemblyinfo.cs' could not be found.
I have this solution:
Source file 'Properties\AssemblyInfo.cs' could not be found
But, it does not work for me.
Actually, I have the 'Assemblyinfo.cs' in working directory, I can see it in VS solution explorer.
Have you tried deleting the assemblyinfo.cs files and then trying Clean and Rebuild solution? If you don't need versioning this might help you.
Have you tried a Clean Solution, followed by a Rebuild Solution?
The AssemblyInfo.cs file should be recreated on a build.
I got this error even after I tried to Clean and Build. I could also could see the AssemblyInfo.cs file. I found out that the build was interacting with a power shell script(not entirely sure how) in the solution directory.
Long story short, Every project, except the one I had added(where the problem was), was mentioned in that script. I added the missing info to that script and I could build again.
I doubt your case will be exactly the same, but I imagine there could be some script or something similar that handles/references all the projects, except the one where your problem persist. Try searching the files for the text of project names.
I have encountered this situation.
I find out why. It is usually due to confusion between mscorlib.dll versions.
There are two ways:
Change assemblyinfo version from 1.0.0.0 to 1.* (change value to *). See link:
MSBuild extensions AssemblyInfo fails with version number not valid
Get an error when trying to set the build version with the AssemblyInfo Task
The second way is simple, I have applied it successfully, that is reinstalling .Net Framework 3.5.
Clean and Rebuild did not help for me.
What helped was manually deleting ALL /obj and /bin files and then using Clean and Rebuild.

How can I resolve the error: "The command [...] exited with code 1"?

I've read around many questions but I've not been able to find the right answer for me.
As I try to compile a project in VS2012 I have this result:
The command "....\tools\bin\nuget pack Packages\Lib.Html.nuspec - OutputDirectory ....\bin\Zip\Packages -NoPackageAnalysis" exited with code 1.
I looked for the line of code in my .csproj file, where the error should be, and there is:
<Exec Command="$(ProjectDir)..\..\tools\bin\nuget pack $(ProjectDir)Packages\Lib.Html.nuspec -OutputDirectory $(OutputPath)Packages -NoPackageAnalysis" />
What am I doing wrong?
[EDIT]
Launching the Debug of that project and ignoring "building errors", I have a new alert:
"Visual Studio cannot start debugging because the debug target '[project.exe path]' is missing.
Please build the project and retry, or set OutputPath and AssemblyName properties appropriately to point at the correct location for the target assembly."
The first step is figuring out what the error actually is. In order to do this expand your MsBuild output to be diagnostic. This will reveal the actual command executed and hopefully the full error message as well
Tools -> Options
Projects and Solutions -> Build and Run
Change "MsBuild project build output verbosity" to "Diagnostic".
Right click project -> Properties -> Build Events
Remove the text in Post-build event command line text block
For me : I have a white space in my path's folder name G:\Other Imp Projects\Mi.....
Solution 1 :
Remove white space from folder
Example: Other Imp Projects ->> Other_Imp_Projects
Solution 2:
add Quote ("") for your path.
Example: mkdir "$(ProjectDir)$(OutDir)Configurations" //see double quotes
Try to open Visual Studio as admin.
For me, in VS 2013, I had to get rid of missing references under References in the UI project (MVC). Turns out, the ones missing were not referenced.
I know this is too late for sure, but, this could help someone as well.
In my case, i found that the source file is being used by another process which was restricting from copying to the destination. I found that by using command prompt ( just copy paste the post build command to the command prompt and executed gave me the error info).
Make sure that you can copy from the command prompt,
This builds on the answer from JaredPar... and is for VS2017. The same "Build and Run" options are present in Visual Studio 2017.
I was getting, The command "chmod +x """ exited with code 1
In the build output window, I searched for "Error" and found a few errors in the same general area. I was able to click on a link in the build output, and found that the error involved this entry in the .targets file:
<Target Name="ChmodChromeDriver" BeforeTargets="BeforeBuild" Condition="'$(WebDriverPlatform)' != 'win32'">
<Exec Command="chmod +x "$(ChromeDriverSrcPath)"" />
</Target>
In the build output, I also found a more detailed error message that essentially stated that it couldn't find Selenium.WebDriver.ChromeDriver v2.36 in the packages folder it was looking in. I checked the project's NuGet packages, and version 2.36 was indeed in the list of installed packages. I did find the package files for 2.36, and changed the attributes on the folder, subfolders and files from "Read Only" to "Read/Write". Built, but same failure. Sometimes "updating" to a different version of the package and then updating back to the original can fix this type of error. So I "updated" the reference in Manage NuGet packages to 2.37, built, failed, then "updated" back to 2.36, built, and the build succeeded without the "chmod +x" error message.
The project I was building was based on a Visual Studio Project template for Appium test tooling, template name "Develop_Automated_Test".
Check your paths:
If you are using a separate build server for TFS (most likely), make sure that all your paths in the .csproj file match the TFS server paths. I got the above error when checking in the *.csproj file when it had references to my development machine paths and not the TFS server paths.
Remove multi-line commands: Also, try and remove multi-line commands into single-line commands in xml as a precaution. I had the following xml in the *.proj that caused issues in TFS:
<Exec Condition="bl.."
Command=" Blah...
..." </Exec>
Changing the above xml to this worked:
<Exec Condition="bl.." Command=" Blah..." </Exec>
I had the same issue. Tried all the above answers. It was actually complained about a .dll file. I clean the project in Visual Studio but the .dll file still remains, so I deleted in manually from the bin folder and it worked.
Hope this helps someone, but I had prebuild events and post build events and it kept complaining about a file called "Microsoft.Common.CurrentVersion.targets" "The target "CoreBuild" does not exist in the project".
Here's what I did to resolve it:
close the project
delete the .suo file (it regenerates)
Asked a team member to provide a copy of that file (Microsoft.Common.CurrentVersion.targets) - mine was different - I took his.
It compiled - good to go.
I must have wrecked that file somehow.
There was no syntax error in my batch file and it ran fine on a cmd prompt outside VS.
So finally, I added
exit 0
to return a success code explicitly at the end of my batch file and it started working.
For me the output file (.dll) of the same version already existed so I guess it was having trouble overwriting. Even though it has never done it before. Anyways, deleting the existing file and running Rebuild fixed it for me.
If the previous method wouldn't have fixed it, my next check would have been to check if the path length was causing it. So would have change the target folder to somewhere close like the Desktop so that the path isnt too long.
Hint: Search for "Exec Command=" in your project
In my case I found following tag in "Microsoft.Extensions.ApiDescription.Server.targets" file, I remarked the line and it worked for me:
<Exec Command="$(_Command)" LogStandardErrorAsError="true" />

a matching symbol file was not found in this folder

I want to use debug symbols, but I am receiving the following error:
a matching symbol file was not found in this folder
What is this problem, and how to solve it?
One of the things I've ran into with was because debug was off on the project referenced where the code lives. In my case, I made a new configuration called "Developer" and by default debug was turned off.
Right click the project in question
Properties
Build
Advanced (right bottom corner)
Set Debug Info to full
Recompile
I had the same problem as #DmainEvent. Apparently the dll that I was using was not the same version as the pdb that I had just compiled, so I got the error message.
If you have this problem, try using the dll and pdb from the same compilation run.
The error I got was "a matching symbol file was not found in this folder" in the Debug => Modules window even after both the DLL and PDB were available and built together, so I was unable to debug into the target DLL referenced by my main project.
Posting this here in case it helps someone browsing with "Mixed Platform" build for target DLL. I did two things to get past this:
In the solution using the target DLL, Uncheck "Just My Code" in Tools => Options => Debugging => General => Enable Just My Code (JMC).
Check "Enable native code debugging" in target DLL solution in relevant Project Properties => Debug.
I tried all the possible solutions, finally it worked when I disabled the option Enable native code debugging under the Debugger engines of Properties > Debug.
I ran into this problem and the answer was simple.
Visual studio has two project level settings that can create .pdb files.
Linker: Configuration Properties -> Linker -> Debugging -> Generate
Program Database File = "xxxx.pdb"
Compiler: Configuration Properties -> C/C++ -> Output Files -> Program Database File Name =
"yyyy.pdb"
You want #1 for debugging. Forget about #2.
Give file #2 a different name than file #1 to solve this error.
I don't know why microsoft specifies #2 as a .pdb file. That is just confusing.
I have fixed my debug symbols, forcing them to match using this tool:
chkmatch tool
edit: the website is down now. the wayback machine helps: https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
So, my problem was I was trying to debug my project and the debugger couldn't step-in to the in-house nugets sources. I had the source files of the nuget project. Still the visual studio didn't accept the pdb files I was trying to show it to.
Showing exact same error:
a matching symbol file was not found in this folder
So, what I did was I added this to the .proj file of the nugets project:
<DebugType>full</DebugType>
And created the dll and pdb file again using the rebuild option.
In the command line I ran:
.\ChkMatch.exe -m name_of_your.dll name_of_your.pdb
It said this:
Writing to the debug information file...
Result: Success.
Great success!
So, next, I referenced this dll instead to the proj I was trying to debug. I worked when I tried to load the symbol again.
Hope it helps.
Without more details as to what you're doing, it's difficult to go beyond "the debugger is looking for a symbol file which matches the compiled code, and couldn't find one in the folder where the compiled code lives."
Some things to think about:
Are you creating symbols as part of your compilation? (check the project properties)
Are you using a symbol server (if so, does it point to the right place)
Is this compiled code from a third party? In which case, as you apparently have the source, compile it yourself.
Consider clarifying your question if you want a better answer. Especially what do you mean by "I want use of Symbols".
For BizTalk (and other) projects, it could be because there's a version of the assembly you're trying to debug already in the GAC. When you run a unit test or hit F5 to debug, a new version is compiled locally. However, the version in the GAC is being used, and the newly created PDB doesn't match the DLL in the GAC.
One way around this is to deselect a build for everything except your unit test project using the Configuration Manager, as shown below:
Well, the solution depends on your specific problem. I tried everything that could be possibly found on Stackoverflow and other sites. One of the thread that I followed is this. That did not help too.
The problem was at once resolved when I noticed that my executable project did not contain a reference to the library that I wanted to debug. So I just added the reference to that project.
**PS: ** This problem might also arise because the assembly referenced by the executable assembly might not match that in the references. So in that case, you just remove the already existing reference and add the new one.
Hope this helps!
The same happen to me because the .pdb file of the project have not been copied to the debug\Bin folder, so the symbols could not be loaded from the .pdb file.
You must rebuild your project and manually copy the symbols (.pdb file) to the debug\Bin folder of executable project.
I was trying to load symbols for a installed nuget package published on our local dev server. I had to uninstall and add a normal reference built from the code instead. This worked for me. Just remember install the original nuget package again once finished debugging.
If it works for you, try to embed debug symbols in the dll itself, so the symbols are loaded automatically. This worked for me in netcoreapp3.1 and net5.0:
<DebugType>Embedded</DebugType>
<EmbedAllSources>True</EmbedAllSources>
Beware that you may find this in documentation:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
but it does not work.
I ran into this with Visual Studio 2022, tried the most of answers here. Fixed by switching back to Visual Studio 2019, seems like a bug in 2022.
My issue was a bit simpler to resolve, but still the issue the question asked. At first, I was not publishing the pdb file with the nuget package another project was using. Once I confirmed that, I removed the nuget package from my project and readded it from our network nuget source. That still didn't let Visual Studio pick identify the PDB location.
Then I noticed that if you select one of your nuget packages, ( Project --> Dependencies --> Packages --> Choose nuget package), there is a Path property. I checked that location and it pointed to %USERPROFILE%.nuget\packages. The pdb was not at this location and the Date Modified was older than the latest package I published. Once I deleted the folder for the given package version, removed it from my project, and re-added it, the latest .dll and .pdb file were added to this location.
After that, I was able to step into the code of my nuget package and had no further issues.
To get the nuget project to produce the pdb file in the first place, I added <IncludeSymbols>true</IncludeSymbols> inside of a PropertyGroup within the csproj file as other answers had directed.
Once I rebuilt that nuget project, it generated 2 *.nupkg files:
Namespace.x.x.x.x.nupkg
Namespace.x.x.x.x.symbols.nupkg
I found this was because the Properties => Debug => Start Action was set to Start external program instead of the Project. So the newly generated pdb file didn't match, because the actual exe was the wrong one.
I have had this problem recently as well.
Was able to fix it by selecting MyProject->Properties->Linker->Debugging->Generate Debug Info->"Optimize for debugging (/DEBUG)".

Categories

Resources