The Generate Serialization Assemblies option in Visual Studio creates a MyAssembly.XmlSerializers.dll when my project is built. This question (https://stackoverflow.com/questions/934411/what-is-myassembly-xmlserializers-dll-generated-for) indicates a reason why it's there in the first place, and some of the answers provide ways to turn it off, but my question is why would you choose to turn it off? Does having it turned on cause problems in certain situations (and, if so, what are those situations)?
Only problems you might be facing are with build tools - such as msbuild, because if you use sgen from x32 SDK on assembly that is explicitly x64 it will raise a build-time error (you can easily overcome this by setting correct SGenToolPath path to msbuild or target MSIL instead). IMHO it is better to deal with build time issues and have quicker startup time.
Turning it off stopped the build and run time errors I was getting as a result of upgrading my application to v4.0. I was getting SGEN errors after trying many of the solutions posted online. Doing this solved that issue.
I had to turn it off when I needed to Sign a "ClickOnce" application. I could not successfully deploy it with the Generate Serialization Assemblies on. The MyAssembly.XmlSerializers.dll had reference in the manifest file, but it is was not part of the deployment package.
Right click your project and select Edit.
Next add this inside "Release" property group
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<GenerateSerializationAssemblies>off</GenerateSerializationAssemblies>
</PropertyGroup>
Related
I've had a problem with my Windows 7 after an update, neither Safe Mode nor Recovery Mode could resolve the problem. I was forced to reinstall Windows completely. To develop on my projects I need Visual Studio 2010.
I always had ReSharper installed and got used to its features, so I installed it aswell.
Everything setup I tried building my solution but encountered a problem ...
(The underlined file can be found here: https://up.zone/aj)
After hours of trying to resolve the problems, I figgured out that ReSharper was the problem. I can build the solution perfectly fine without ReSharper installed. Having it installed, even if all features are turned off and the services are suspended, causes these errors in the picture above to show on build.
I managed to resolve two out of three errors by following the instructions of this Reddit user on his post: https://up.zone/ag
Now I am left with one more exception I cannot figgure out how to resolve. I couldn't really find anything helpful googling, which means you guys are my last hope. I really do not want to go back to developing without ReSharper.
This is the one:
Any idea?
Thank you!
Update 1
I figgured out that the problem must be in the NuGet.targets file, located in the .nuget folder in our solution.
I managed to find a workaround following the suggestion of this post, I am now able to build the solution without any errors.
To summarize, remove this line out of your *.csproj file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Although this works, I don't think this can be the solution. This line is there for a reason I assume. Anybody with a deep understanding of NuGet who might know how to properly resolve this problem?
Update 2
I found out that as soon as you reload your solution/project, the line gets added once again. Also, if you have certain dependencies nuget should download for you - it won't, because the line which makes that call and handles this got removed.
I'm now at a point where I know where the problem is but not why it is caused.
Does ReSharper change anything in the way NuGet behaves? As far as I can tell, nothing gets added or removed to or from the NuGet.targets file due to ReSharper.
There were one more report on this topic, at https://youtrack.jetbrains.com/issue/RSRP-462271 .
The best guess so far is that this is caused by two things happening at once: (a) using MSBuild tasks in C# source code form inside MSBuild XML files rather than DLLs and (b) having some of the MSBuild opensource DLLs shipped with the latest version of ReSharper for its own project file handling needs.
The source code gets compiled into a task DLL during an MSBuild run (not a much common thing to have; Roslyn would do this rather than ship a DLL? seriously?). When building from within Visual Studio (rather than with msbuild.exe), the in-process MSBuild instance is used, and it would run in the same appdomain as ReSharper, so it uses the common assembly reference resoluiton. If it's not too accurate, then it might accidentally pick the wrong DLL version by the short name, which would break the task compilation (that's a separate error, maybe cached away) and then result in the task-not-found error later at runtime (SetEnvironmentVariable task not found in here case).
I've tested on sample solutions with source code based tasks and could not get it broken. So trivial cases are OK. Never heard back from the original issue reporter, so there was no further progress.
Now I've got a hint that this is Visual Studio 10 (any other VS versions installed on that machine?) and maaaaybe it's Roslyn tasks. We might know for sure if you run MSBuild with more detailed logs (by setting the logging options at Tools | Options | Projects and Solutions | Build and Run | MSBuild project build output verbosity to at least Detailed) and building just the faulty project.
I'll also try this out with VS10 and update this reply with new data.
Visual Studio (at least VisualStudio 2010) stores the target platform settings in the *.suo file which obviously shall not be version controlled.
In my case this is no problem for the central build because that uses a command line option on msbuild that force the target platform to be x86 as required.
However, if a colleague checks out my project he will always end up building for AnyCPU and testing that. Because he has no *.suo file VisualStudio will use the default settings.
Bad or not, the colleague is obliged to test for x86.
Is there an easy way to safely persist the target platform for a Solution? An environment variable forcing the default is not exactly what we need but would be good enough and easy enough.
Visual Studio ... stores the target platform settings in the *.suo file
It doesn't, it stores it in the project file. A relevant snippet from one I created:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>x86</PlatformTarget>
// etc...
</PropertyGroup>
It is configured with Project + Properties, Build tab, Platform target combo box. Repeat for the Release configuration. Only the setting on the EXE project matters, that's the one that determines the bitness for the process. DLLs have no choice and ought to use AnyCPU.
In all likelihood you are being tripped up by a rather drastic design mistake in VS2010. Another item is the solution platform name, prominently displayed in the Build + Configuration Manager dialog for example. This was always AnyCPU for managed projects, VS2010 screwed this up royally by renaming the default to "x86". And creating a big old mess of it when you import projects from earlier versions, yielding a "Mixed platforms" configuration. And yes, the last selection is saved in the .suo file.
This is irrelevant to managed projects, it only matters to C++ projects. Where the setting selects a different set of build tools. The 64-bit compiler and linker are different programs. A non-existing issue for managed projects, bitness is determined at runtime by the jitter selection and you use the exact same C# compiler regardless of the desired platform target.
The best way to eliminate these kind of mistakes is by aggressively deleting platforms and only keeping one. Use Build + Configuration Manager, select the "Edit" entry in the upper-right combo box and click Remove for extraneous platforms until you only have AnyCPU left. Updating your VS version is also recommended, this mistake was corrected again in VS2012.
I am trying to build MSIs in a TFS Build by shelling out to DEVENV.exe (since MSBUILD does not support VSPROJs). In any case, my first installer project builds fine, the second one fails. If I reverse the order, same thing happends (i.e. the error does not follow the project). Looking at the output, I get the following errors:
Deserializing the project state for project '[MyProject].dbproj'
[MyProject].dbproj : error : Error HRESULT E_FAIL has been returned from a call to a COM component.
Also, I get:
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load
It looks as though the first build tries to serialize the DB project (and it says it succeeds, but there is no DBML file anywhere). Then the second build tries to deserialize the DB project and fails.
I've tried resetting env settings (using the /resetusersettings flag) as well as using the /resetskippkgs flag. Nothing works.
Any ideas?
When you shell out to DevEnv, are you building that specific project (.vdproj file), or are you building the solution? It sounds like VS is trying to open the solution on the build machine and the database and test project systems aren't present.
Have you considered porting your setup project to WiX?
Start simple. Unless you're well versed in the problem you're trying to solve it's usually best to try it "by hand" before getting it running as part of a TFS build. RDP into the build server and try running the necessary commands at the command line and see what happens. You can even go simpler than that and RDP into the build machine and load Visual Studio and build it.
Bottom line is that if you can't get it to build within Visual Studio or at the command line by calling devenv.exe it won't work as part of the team build.
I am using the below Exec task to do precisely what you are doing as part of a TFS build. So I know this works. Your platform and configuration may vary depending on what you're building. The nice thing about this is that you'll have a log file at C:\Temp\MSIBuildOutputLog.txt that you can analyze for additional errors and information.
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" "$(PathToSolution)\solution.sln" /Build "Release|Mixed Platforms" /out "C:\Temp\MSIBuildOutputLog.txt"" />
One important thing to note... There is a bug in VS2010 which causes MSI generation to fail when you try to run it at the command line using devenv.exe. This took me days to find and figure out, but you need this hotfix. Worked like a charm...
http://archive.msdn.microsoft.com/KB2286556
Actually it's the deployment projects that don't support msbuild. FWIW, this is all deprecated in the next release of Visual Studio so you might want to start looking at InstallShield Limited Edition and/or Windows Installer XML now before spending too much time on dead end, broken technology. Both of these alternatives have proper MSBuild support aswell as many other improvements.
It would be perhaps better and quicker to adopt WIX (Windows Installer XML) which is the technology MS now recommends to use within VS/MSBuild/TFSBuild environment to crate MSIs.
It is relatively easy to setup and integrate within your VS Solutions. It uses XML based files to describe your MSIs and uses these files to create your MSIs when you compile.
I would start by downloading Wix from http://wix.codeplex.com/
Once installed you would be able to use the VS2010 integration of Wix based projects to create MSIs. To get started quickly simply add a new Wix project to your solution and reference the projects whose output you wish to combine into an MSI. Next you can run a tool called "Heat" which is included with Wix toolkit to generate the XML files by scanning your projects.
Once you have these XML files, add them to your Wix project and compile.
Visual Studio sometimes decides to rebuild my entire huge project because of one small change. I turned build logging up to Diagnostic to see what was the problem, and here's what I'm seeing:
< Bunch of spam >
Outputs for C:\<snip>\PRECOMPILEDHEADERS.CPP:
C:\<snip>\PRECOMPILEDHEADERS.OBJ
All outputs are up-to-date.
Forcing rebuild of all source files due to a change in the command line
... and then it rebuilds my precompiled headers, then everything else.
This happens when I change a single .cpp or .h file inside the project. I'm not changing anything in the project settings. It also doesn't happen all the time for the same change; it's random.
Any ideas on what's going on here? Where can I get more information? I tried enabling debugging via the description in http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx but it didn't give any more information. I can't figure out where this "Forcing rebuild of all source files due to a change in the command line" is coming from. It's not in any of the factory MSBuild files.
Some other info: it's a C++/CLI dll project that links a lot of other projects, including C#, native c++, and other C++/CLI dll's. I tried removing all the C# projects from the dependencies since those tend to cause problems, but that didn't change it. I've googled that specific string, but my situation doesn't match that of any of the other people reporting it. (One was using Intel C++, another was MSBuild from the command line and changing the case. I'm hitting build solution from within Visual Studio itself).
Edit to explain common fixes I've tried:
I've tried building only the project. Does the same thing.
I'm not including any .h files that don't exist.
I've deleted the bin/object folders and rebuilt from scratch. This usually makes it go away for a couple builds, but then it comes right back.
Edit #2:
Found something suspicious earlier in the log:
3>Using "ResolveNonMSBuildProjectOutput" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "ResolveNonMSBuildProjectOutput"
3> Resolving project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj".
3> Project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj" has not been resolved.
This is repeated for several of my projects... I'm gonna chase that down and see if maybe it's a problem with the project reference hint paths.
Ok, it's an old thread, but I encountered the same problem recently.
My solution was to disable the precompiled headers - now a simple change in one sourcefile won't lead into a "rebuild" any more.
I have had the same problem with Visual Studio 2012 recently. I'm on Windows 7 with Visual Studio 2012 Professional (2012.2) building C++ projects. It's worth noting that I recently migrated the solution from Visual Studio 2008 to Visual Studio 2012.
One of the C++ projects (an executable with a DLL project as a reference) was rebuilding every time one of its compilation units was changed, e.g. simply saving main.cpp would cause all compilation units (including the pre-compiled header) to rebuild. I spotted the the following message in the build logs:
Forcing rebuild of all source files due to a change in the command line since the last build.
I turned build log file verbosity to Diagnostic (Tools > Options > Projects and Solutions > Build and Run) and compared the log files from a clean build and a build after one compilation unit has been changed (which forced a full rebuild). I noticed that:
"Path" had changed from one build to the next (";C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\VsGraphics" seems to have been tacked on the end)
there was a difference in TaskTracker.exe command lines to do with CancelEvents
there was a warning about OutputPath not being set
I pulled my hair out.
I eventually resorted to recreating the offending project from scratch rather than relying on the project that was automatically generated during the migration process from 2008 to 2012. It seems to be behaving as expected now.
I did three things, and the problem seems to have gone away. I'm trying to narrow it down a little but I figured I'd go ahead and post them:
Deleted and re-added all the references and project references
Fixed one of my projects that wasn't setting the .NET framework target to 3.5 to match the rest of my solution (I was getting away with it because the project didn't use .NET anyway)
Set "Copy Local Satellite Assemblies" to false for all references including System ones.
Beware that some or all of this stuff might be voodoo...
If one project can't build, Visual Studio, by default, keeps right on trying to build all the other projects that depend on that project, and therefore gets stupid errors because those other projects are now building against a stale version of the binary.
How can I change this behavior, and get it to stop on failure?
For example, suppose I have a library project called MyApp.Core, and an executable project called MyApp. MyApp calls a method in MyApp.Core. Suppose I add a new parameter to that method and then try to build, but I've inadvertently introduced an unrelated compiler error in MyApp.Core. When I build, Visual Studio will:
Try to build MyApp.Core, and fail because of the compiler error. The MyApp.Core.dll on disk is left unchanged because the build failed.
Go on to try to build MyApp against that older version of MyApp.Core.dll, and report compiler errors because it's passing more parameters than the method in the old DLL expects.
Report the second batch of errors at the top of the Errors window, thus making it very difficult to find the actual problem.
Make has had this problem solved since 1977: when it realizes that it can't build, it stops building. Every other build system and IDE that I've used is also clever enough to stop on a lost cause. But Visual Studio hasn't quite caught up to the technological sophistication of 1977.
The book "Visual Studio Hacks", in its section on macros, has a workaround: you can write a macro that fires when a project is done building; if the project's build status was "failed", the macro can issue a Cancel Build command. I regularly install this hack on every computer I use that has Visual Studio. However, at home I use Visual C# Express, which doesn't support macros.
Is there any way to get Visual Studio 2010 (including the Express editions) to stop building on a build failure?
As much as I like MSBuild, there isn't a built-in way to do this when using the solution file to build (as you've already discovered). With Resharper's analysis enabled I find that compiler errors are very rare for me these days, so I rarely have the problem of overwhelming error messages.
At my previous shop, someone routinely gacked-up the build so that one of the root projects in a solution of over 60 projects and because of that, many people took to running projects individually from the command line similar to running individual Make files.
If you really wanted to handle this problem in a different way than the macro you mentioned, you could construct an external msbuild file that executes the projects individually and checks for errors in-between runs. You'll have to keep the build ordering correct, and you'll need to run it from the command line and/or add a shortcut to the Tools menu option.
Here's an example:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<MSBuild ContinueOnError="false" Projects="log4net\log4net.csproj" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
</MSBuild>
<MSBuild ContinueOnError="false" Projects="Project1\Project1.csproj" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
</MSBuild>
<MSBuild ContinueOnError="false" Projects="Project3\Project3.csproj" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
</MSBuild>
</Target>
<!-- <OnError ExecuteTargets="ErrorTarget" /> //-->
</Project>
Replace the projects with your projects, and the group will need to be mimicked for the Clean target.
I wish there was a better solution and I don't know why the MSBuild team won't add this feature into the product. Like you said, Make figured it out decades ago. FWIW, I don't know how well this works with complicated build dependencies and build parallelism.
My problems with MSBuild center around the ResolveAssemblyReferences, and ResolveComReferences Tasks which are the slowest part of a build in a big solution with a large/complicated project dependency tree (large being relative ~30 projects at a minimum).
I hope this helps.
There is also this free extension for Visual Studio 2010/2012/2013 that does this.
StopOnFirstBuildError (Download)
http://visualstudiogallery.msdn.microsoft.com/91aaa139-5d3c-43a7-b39f-369196a84fa5
Stop Build on first error in Visual Studio 2010 (Write-up)
http://einaregilsson.com/stop-build-on-first-error-in-visual-studio-2010/
You can also kill the process called cl.exe using the task manager. There might be multiple cl.exe processes - killing just one of them should be enough.
This will stop the build process immediately.
I always just hold down the "Pause / Break" key when I see it happening and it cancels the build.