My problem seems to be relatively simple. I have a c# solution created in VS2010 with several projects with project references configured appropriately. I use MSBuild on our build machine which works fine, building in the correct order incrementally to be efficient. However, if I extend the interface (adding a public property etc.) and increment the AssemblyVersion of one of the projects that others depend on, it seems that MSBuild is unable to refresh the caching on down stream dependents and throws an error that it cannot find the previous version of the changed dll. Interestingly if I run the build again immediately afterwards, it tells me that the output hasn't changed and completes the build without error but I have no longer any confidence that it has done the right thing.
There is a file 'ResolveAssemblyReference.cache' that seems to hold the old reference and if I delete this from the obj/x86/Release folder before each build I never receive any errors but don't know if the output has/should have been rebuilt.
I would like to understand why MSBuild struggles with this and why on a second build it seems to report that the first build did actually work and that the targets are up to date.
Until I understand what is going on I am going to have to always force a rebuild of the entire solution to be certain I have compatible files.
Incidentally if I build in VS2010 I never seem to suffer this as I suspect it updates that cache appropriately each build.
Update:
I have found that my use of 'OutDir' on the command line for MSBuild seems to be to blame. If I remove this then the referencing seems to be resolved appropriately. However now I do not have my output copied to where I need it for deployment...
Related
I'm building a WPF app w/ Visual Studio 2015 (Update 3), and—at least by now, I'm not sure for how long this has been the case—every time I make a change and compile, I'll get a failed build w/ the error
6>CSC : error CS2001: Source file 'C:[...]\Obj\Debug\AnyCPU\GeneratedInternalTypeHelper.g.cs' could not be found.`
If I just build a second time, though, it works just fine.
This smells to me like a dependency on another file that is generated afterwards or something like that, but I haven't been able to find out what it is, a google search didn't net anything either, and neither did a search through my project what this file is used for in the first place (the name suggests its purpose, but I don't know where exactly it is used).
It might also be that the (group-policy-mandated) Anti-Virus is holding an exclusive lock on the file or its dependency for a moment too long, and VS stumbles over that, I think I remember a problem like this at my last job, but I'm not sure that is the case (and I can't simply disable the scanner for a check, it's completely locked down and I don't want to violate company policy for trying to circumvent it).
Any ideas? It's not critical since it's easy to work around, but it's annoying and I don't really want to check in the project like this in the end.
I had the same issue and i found why it happened (in my case).
Every project of our solution has the same output folder.
The file GeneratedInternalTypeHelper.g.cs was generated at the same place for each project.
The build order/dependencies were computed and Visual Studio found that some project could be build in parallel.
In Tools > Options > Project & Solutions > Build and Run you can find the option "Maximum number of parallel project builds.
After changed from 8(in my case) to 1, no more files generated at the same time :)
It is a little slower to compile but really less annoying than compile multiple times... \o/
An alternative solution is to add project dependencies in the solution for the projects you don't want to build in parallel.
With this you can keep the parallel project build for the other projects.
I have just chased down the same error. In my case it was caused by Git checkout inserting a "%20" into the folder name of the solution where a space was expected. Replacing "%20" with space fixed all these missing *.g.cs errors. Thought worth mentioning here.
I'm using TFS 2010 and have a TFS build setup to build our software. Everything is working just fine.
But, we are getting the following warning:
CSC: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor
This is because some of our code is marked as x86 only, and it is being built on an x64 platform. We cannot change the target platform because of third party software we link to.
Also we are targeting the 2.0 framework, which also cannot be changed at this point.
So, I want to simply suppress this error. Seems straight forward enough.
I simply edited the Build template, and added /p:NoWarn=1607. That works.
BUT!
We have ONE solution which is written in VB.net, instead of C#. This causes that one solution to fail with the following error:
vbc: warning number '1607' for the option nowarn is either not configurable or not valid
How do I disable suppressing this warning on that one solution in my TFS build?
I tried to use a <customPropertiesForBuild> tag in my TFSBuild.proj file but I'm probably not using it correctly.
I know I could simply add this to my project files, but we have 37 solutions, each with multiple project files, so I really don't want to do that.
I don't think you can control that suppression from TFS since it is MSbuild complaining during build (and TFS simply calls MSBuild and collects the results).
There's a specific property that tells msbuild to ignore this kind of warning. Simply add the following line to your top Propertygroup in the project file for those projects generating the warning:
<PropertyGroup>
...
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
You should be able to use Properties metadata on the VB solution's SolutionToBuild item to set NoWarn to an empty value just for that solution:
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../MyVbSolution.sln">
<Targets></Targets>
<Properties>NoWarn=;</Properties>
</SolutionToBuild>
Try that and see if your VB solution will compile without errors.
You can provide a NoWarn Property to MSbuild in TFS Build. One idea also is to edit the build definition, in the "Process" Tab, explore the Advanced=>MSBuild Arguments, and then you supply this "/p:NoWarn=1607" without the qoutes. When you also queue a build, in Parameters Tab=>Advanced=>MSBuild Arguments, enter/p:NoWarn=1607.
I've just come across a pretty strange problem with VS2010 and Script#, which most of the time I am able to re-create.
In my simple scenario I have 2 projects in my solution; a standard Asp.Net MVC2 Web Application, and a Script# jQuery Class Library. I created a static class (attributed with [Imported]) with a static method on it, the intention being that I can map this class in code to an external Javascript library, as described in the documentation.
However, it seems that whenever I decorate such a class with [IgnoreNamespace] to achieve this goal, the project stops successfully compiling but doesn't give me any feedback as to why it's failing (no errors in the error window, for example). It's not easy to get rid of either, as Visual Studio seems to get into a permanent state of not build failure; removing the classes and project files doesn't solve it, nor restarting visual studio. The only way I can get VS to build the project successfully is to delete the project entirely, create a new one then add the files back in, which is annoying to say the least.
With a verbose build output setting, I get the following:
Target "AfterCompile" in file "C:\Program Files (x86)\ScriptSharp\v1.0\ScriptSharp.targets" from project "e:\project\local\ScriptSharpDemo\Scripts\Scripts.csproj" (target "Compile" depends on it):
Task "ScriptCompilerTask"
Done executing task "ScriptCompilerTask" -- FAILED.
Done building target "AfterCompile" in project "Scripts.csproj" -- FAILED.
.. which doesn't tell me whole lot.
There have been a couple of times where I have managed to create this type of class and then successfully build, but mostly I can reproduce this problem pretty reliably.
At this point I'm inclined to think that the bug lies with Script#, but would just like to have that confirmed, and to find a possible work around if there is one.
Just in case anyone is having a similar issue, I've found the cause of the problem.
When adding a class using this method, or copying in a file from another project for use within Script#, this causes a reference to System.dll to be added to the project. This (understandably) causes the project to stop compiling without error.
It would be nice to have a warning about this or for Script# to somehow detect when this situation occurs and/or create a new template for when I use 'Add class' or import a file, but it is just a convenience issue and at least now I can painlessly get my project compiling again just by removing this reference.
When trying to make my project build again, I came across the following, possible solutions:
The "Home\HomePage.cs" and "Shared\Utility.cs" must not be deleted and remain where they wre initially created
The "Home\HomePage.cs" and "Shared\Utility.cs" must be the last entries in the "*.csproj"-file. After them, no "Compile" tag should follow
Problematic calls to "Script.Literal" might cause silent fails - especially be careful when having parameters (like Script.Literal("{0}.doFoo()", variable))
The same seems to be true for "String.Format" when the format parameters are invalid
Namespaces and folders seem to cause many problems, putting all classes into the same namespace and all classes into the same folder might help
I tried all of the suggestions that have been given here, but continued to see the issue. Eventually, I determined that the cause in my situation was that I had added an [IntrinsicProperty] attribute to one of my properties. Removing it solved the issue. Don't ask me why this was causing a problem, but I thought I would share this solution in case others run into it.
I'm maintaining a c#.Net (vs2005) library, let's call it fooLib, developed by a coworker. Now management has decided that we should change it's name to, say, barLib.
So I have renamed it, changed some of the metadata (copyright info, etc), registered it in gac, removed the reference and added it again in each project which uses it, and voila!
So far, so good, but there's a project which uses it, that gives me some weird error when linking the Debug version, while the Release works like a charm, without a warning.
It gave me a way long error message telling me that it cannot found fooLib.dll (when it should be searching barLib.dll) and told me that linking log was deactivated, and the way to activate it. So I did, but the only new information returned is the list of paths in which it's searching for the wrong file.
Any idea how can I fix this without having to rebuild the solution from scratch?
Take a look in the project file - make sure nothing odd is going on there for different configurations.
Build the solution from "ultra-clean" - manually get rid of all the bin/obj directories.
When you say there's a problem "linking" the Debug version, do you mean it fails at execution time rather than compile-time?
It seems that changing the build target from 'Any CPU' to 'x86' or 'x64', it works. Changing the Release Build (which was set to x86) to 'Any CPU' it fails with same error
But it was working as it was before the library's name change. Seems quite frightening...
Edit: Now it's getting really funny. If I set the project config to "Release|Any CPU" with register for COM interop unchecked, it compiles fine. Then I can go to debug, mark the COM checkbox, and it still works fine. Then I return to release, with the interop option checked, and it fails. I return to debug, and it fails, too.
I am using Visual Studio 2005, .NET 2.0
I am not really sure yet under what circumstances it happens, but here is the scenario:
I have a solution with a project structure like this: A library project Foo, a library project Bar which references Foo, and a library project Quux which references Foo and Bar.
Compiling fails with the Error message "Metadata file 'Foo.dll' could not be found" from Bar, and "Metadata file 'Foo.dll' could not be found" and "Metadata file 'Bar.dll' could not be found" from Quux.
Looking in my target directory (I have a combined target directory for all 3 projects), it is empty, so no project at all is compiled. Now I can get that Bar and Quux fail if there is no output from Foo. Problem is: Why does Foo silently fail? There is no error from it, and just building Foo instead of the entire solution works fine.
The "funny" thing is, after just pushing the build button again, the Foo.dll file appears, Bar no longer complains but does not produce any output file either, and Quux complains about missing Bar.dll. Pushing the button again, the Bar.dll appears, there are no more errors but no Quux.dll. Only after pushing the button yet again, the Quux.dll appears, once again with no errors.
The project dependencies are all set correctly, the solution build order says exactly the right thing.
I have even tried creating a new solution and new project files, then adding the sources again to those. No joy, either. Same thing happens.
I am completely stumped. Does anyone know a way out of this mess?
You should have separate output directory for each project. Each time a project builds, it clears the output directory, so it won't find any dependencies on the next one.
Don't fear losing any DLLs, they'll be copied on each bin directory where they are needed.
I think a work around to your problem could be using post build events that deletes previous version of your dlls and copies the new ones to your combined target directory.
When you set up the three projects to work this way, you will find that you are compiling each project to it's correspondent bin folder and to a combined target directory. There is a second thing you should do if you decide to work with this, set up for each project in your solution a reference path pointing to the combined target directory. Compiling order must still exist.
This way each project dll will be found in the combined target directory, each time you compile.
Although, this solution has it's own problems such as when a post-build event forgets to wrok properly; but it's rare.
Hope this helps
The problem is build order. If some project depends on another then that second project must be built first. Use build dependencies in the solution properties to overcome this.
Check you build order so that all seems right there..
Try to run a clean solution and build again is this when it happens?
Drag your project file into note pad and Find with "Import" tag
and replace that tag with this
Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"
Its should work
For reasons unknown, this happened to me with Visual Studio 2013 in the middle of a morning's work. One build, it was updating the dll, the next, it just wasn't, even though the build seemed to go smoothly. I finally addressed it by deleting the existing dll. With no pre-existing dll, the build had to provide a new one.
I agree that each project should have its own target directory. I have tried to get cute with this and it always causes more trouble than whatever I was trying to get around.
I have a vs19 , 5 project solution. I just added a new console app. THis app started suddenly compiling without complaint but did not produce files. the unit test project that depends on it complained.
I did the usual
clean / rebuild
clean / rebuild each project in order
check the project dependencies and the build order
restart vis studio (in know its 2020 and i still have to restart vs sometimes)
faced w/ the prospect of just creating a new project, i decided to try one other thing
removed all references to other projects
commented out all the code that depended on these.
i was left with pretty much a main() that returned a 0
this compiled and produced files
one by one i added the references back until everything was there.
uncommented the code.
at the end of this exercise things worked.
I can not tell you what changed.
Thought I would offer this as a trouble shooting method.