I'm not sure if this is specific to 2010. But, when I do a clean, I get several errors saying "Cannot unregister assembly XXX.dll. Could not load file or assembly XXX or one of its dependencies. The system cannot find the file specified." However, if I clean again, it works. Any ideas?
I ran into and posted about this recently and found that, from the sounds of things, this is an issue with MSBuild itself and the way it resolves dependencies. My situation is slightly different from yours, though: When I run Clean through the VS IDE, it goes off without a hitch, but when I run the Clean MSBuild task, I run into the error you opened this thread with.
In my case (I'm attempting to automate our build with MSBuild), the quick and dirty fix was to use the Exec task instead of the MSBuild task to clean (and build) the solution. For the Exec task's Command parameter, I use devenv instead of devenv.exe--although this still requires an installation of VS on the build machine, unfortunately.
I suppose another option (requiring more time than I have now) might be either to write a custom task that correctly determines dependencies and runs "Clean" against each in proper order, or write one which catches the "Could not load file...' exception and loops through the clean task until it the exception no longer pops up. (This latter seems more brute-force in approach, but might be quicker.) I'm kind of new to this, so both ideas might just be worth no more than a quick flushing.
In either case, if since starting this thread you've come up with a solution, I'd love to hear about it. Good luck.
Related
I am trying to run msbuild command line, but, I am getting in the last step of it, the error below (it is in portuguese, but is the same error in the title.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Xamarin\iOS\Xamarin.Shared.targets(227,3): erro
r MSB4044: A tarefa "GetMinimumOSVersion" não recebeu um valor para o parâmetro obrigatório "SdkVersion". [E:\2-PROJETO
S\_ALGORIX\Projetos\ACCORD\SOLUTION\AppAlgorix\AppAlgorix.iOS\AppAlgorix.iOS.csproj]
My msbuild command is:
msbuild AppAlgorix.sln /p:Configuration=AppStore;Platform=iPhone /p:CFBundleVersion=1 /p:CFBundleShortVersionString=2.3.1 /p:ServerAddress={mac ip address} /p:ServerUser={mac user} /p:ServerPassword={mac pwd} /p:BuildIpa=true /p:IpaPackageDir="E:\8-IPAS\ACCORD" /t:Clean;Build /p:ArchiveOnBuild=false /p:IsAppDistribution=false /p:CodesignKey="{App ID identifier}" /p:CodesignProvision="{App Provisioning Profile}"
All the {} data are confidential, so I cropped them.
This command was working one day, but I don´t know when, but after some VS 2019 update, the command, stops working.
I have found some articles about it, but I can´t find a way to resolve this problem.
Onw of those articles is this:
https://www.gitmemory.com/issue/xamarin/xamarin-macios/10109/729614745
My VS 2019 is updated in version 16.8.4.
I have here, about 40 apps to build and get the ipa. I was running a dosbat to resolve it, and get those ipas, more quickly. Not having this msbuild command line working, will take me to a big problem, cause I almost every week have some updates in my apps, and build one by one, will not be a great idea.
And one more thing is.. I can build inside VS 2019, without any problem. The problem happens only via msbuild command line.
I used the post Visual Studio update (16.8.1) lead to CI build failures to resolve the error.
"This has reared it's head again in Visual Studio 2019 version 16.8.3.
Looks like they've moved the problem to: \MSBuild\Xamarin\iOS\Xamarin.Messaging.targets I was able to get
my builds running again by removing the _SayGoodbye dependency on line
52 for the _DisconnectAfterClean target."
Although I have resolved the error, now I cant generate the ios.ipa package. Now, I get only the file projectName.iOS.exe, instead of projectName.iOS.ipa.
I dont know if this workaround is the final solution for this bug, yet.
We resolved this by running the build twice in-a-row. (continue on error - ignore the failed first build)
The first time always fails with the error in the question title, but it must somehow sets things up so that the second build has what it needs to succeed. The IPA is generated, etc.
IMPORTANT: DO NOT CLEAN BETWEEN THE TWO BUILDS
I know this solution is a hack workaround, but I prefer it to manually making changes to the .targets files as I have seen suggested elsewhere (those suggestions did not work in our case anyway). Making changes like that without knowing the internals of the build process intimately could result in unintended side-effects.
NOTE: As this solution involves an expected failed partial first build, it does add to the build time, but it was only about a minute or two longer per build, and at least it works reliably.
Hope this is helpful to someone! 🤗
I am working with a VS2010 solution we have inherited. It has approx 300 projects. Medium term I will try to break this down into multiple solutions, but I can't do that immediately.
One immediate problem is that if I do 2 consecutive builds, the second still does a lot of work, which says to me that something is wrong with the "make" configuration. What is the best way of analysing the build config to determine incorrect dependencies or other problems?
Is there a tool for doing this or shall I try and make my own? Thanks.
(The solution was migrated through VS2005 and VS2008 before getting to VS2010 which probably didn't help the build config)
The 'lot of work' from the second build could be just actions in the PreBuild steps, which are always executed. Make sure you get at least 'normal' instead of 'minimal' build output (Tools->Options->Projects and Solutions->Build and Run). Just looking at the second output should give you the information you need. As far as I know there's no tool to compare to build log files, but it shouldn't be too hard to write it yourself.
I recently run into problems when running all my unit tests at once.
I can debug them and run my tests seperate without problems, but when running them all together, the test-run keeps hanging half way through.
This happens:
"Run all tests in Solution"
The first tests parses without problem (slower then usual though)
At some point it gets stuck. Nothing fails, no exceptions, VS just stops running the pending tests.
When stopping the test-run it gets stuck again, and I need to restart VS to abort the test-run.
Normally I would expect a bug in my code, but I haven't made any changes to the code beeing testet since last succesful test-run. The only thing I did was run Performance Wizard - Cuncurrency profiling.
It always stops the same place, when removing some tests from the run it stops a new place (still without actually entering any leftover tests).
I have no clue what is causing this. But seems like I'm having problem with a VS setting rather then a code Error.
Any suggestions? Do Performance Wizard change any settings that might have influenced the way test should be run?
System details:
Windows 7 Ultimate 64-bit,
Visual Studio 10 Premium
This sounds like a concurrency issue. It seems that one test changes the testenvironment in such a way that another test runs into a deadlock. When you remove some tests, the test run order is changed and some other tests get stuck.
So I would look for a concurrency issue regarding your test environment/externall dependencies.
I can't really explain why this works, but it solved the problem!
I reversed the '.csproj' file to an earlier version, in one of the projects that had been in 'contact' with the Performance Wizard, and now my tests works.
ALSO Be aware of that Performance Wizard can change the solution configurations from 'DEBUG' to 'RELEASE' mode in some cases. This was not the case for me, but have been a pain for some of my colleagues.
I have no idea how this started so I'm guessing there's a setting somewhere that I've been unable to find. I have a test that calls a method but when I run debug, it simply will NOT step into that dll. At all. Period. Throws an exception just fine, but it's kind of worthless when I can't step into see what's actually going on.
When another team member picks it up, he's able to debug the exact method I was attempting to target. Yes, same breakpoints, yes, same code (I checked in, he got it, ran just fine)
What the hell?
update : checked the test project for stupid entires, deleted the debug/release folders for fun, I've went though and dumped the project completely and got it back out of tfs. I've nuked the appdata/local/ms/vs/10.0 folder and the /appdata/roaming/ms/vs/10.0 folder. Deleted the local test results.
You probably need to investigate your project references. Is the DLL possibly GAC'd? Take a close look at the *.csproj file.
The fact that it can be debugged no problem on someone else's machine indicates to me that you're having an environment issue. Some sort of multiple library reference issue.
Another possibility: Visual Studio (and all its embedded tools) can have many strange caching behaviors. You might want to clear out extraneous MSTest-related temporary cache files/dirs.
Ok, got it. You can't do one of those things and it works. I had to do them all prior to opening up vstudio again. It'll blow your settings away just as a heads up.
Kill the AppData/Local/Microsoft/visualstudio/10.0 folder
Kill the AppData/Roaming/Microsoft/visualstudio/10.0 folder
Kill your entire project ... all of it.
Get latest (force)
And it works again.
I have a solution with several projects, where the startup project has a post-build event that does all the copying of "plugin" projects and other organizing tasks. After upgrading the solution from VS 2005 to VS 2008, it appears as though the post-build event only fires if I modify the startup project, which means my updated plugins don't get plugged in to the current debugging session. This makes sense, but it seems like a change in behavior. Is anyone else noticing a change in behavior with regard to which projects get built?
Does anyone know of a workaround that I can use to force the startup project to rebuild whenever I hit F5? Perhaps I configured VS 2005 to work this way so long ago that I've forgotten all about it ...
I think you need to reorganize the responsibilities. Each component should be responsible for itself and therefore copy its generated goodness where it needs to go. That way it doesn't matter if/who/what/when/where got built. Whatever is updated will put itself into the proper place.
IMO the other suggestions are no-nos since they'll circumvent the compiler's smarts to know when a rebuild is necessary for the main project. And hence killing any compile time-savings. If your "plugin" projects are assemblies (and not just project-references from the main project), then you do not need to rebuild the main project each time a plugin is rebuilt. The new assembly will get selected into the process / debugger w/o the main project needing a rebuild.
Why not just add a dependency to the "startup" project for each of the plugins? This will force the project to be rebuilt if any of the others change, and you won't have to mess with any other pre/post-build events.
I don't know if this is the right way to do it but you could add a prebuild event to your startup projcet (if it's static) to clean the project which will force a rebuild.
something like:
devenv project.csproj /clean
This is a pain. What we really need is for Microsoft to allow us to hook into a Post-Solution Build event. You can do this via macros but that's too complicated.
I'm assuming this is a C++ project because I don't have this problem with C#.
This is my solution, it's not elegant but it works:
Create a new project whose only purpose is to run the post-build script. Mark it as dependent on every other project in the solution.
Add a dummy file to that project called dummy.h or whatever.
Right click on dummy.h in Solution Explorer and select Properties.
Select 'Custom Build Step'.
For the command line type 'echo' and for Outputs just type 'dummy' or something else that will never exist.
This project, and therefore the post-build script, will now be run on every build.
John.
flipdoubt: they are projects created originally in 2008. My suggestion if it's not working C# is to look in the Build Events tab and check the setting of the "Run the post-build event:" drop down. If it is set to 'When the build updates the project output' this might be your problem, try setting to 'On successful build'.
John.
I'm having the same issue here and it is VERY annoying. John Richardson is right in that there should be a Post-Solution Build event (and a Pre-Solution Build event) that applies whenever ANY project in the solution is being built.
I don't think there is any good workaround to get this outcome in the current VS 2008 IDE.
Starting from #lomaxx suggestion, I got a very similar setup working by adding the following line at the end of the post-build event of the startup project:
"$(DevEnvDir)devenv.exe" "$(ProjectPath)" /clean
Note that this makes the startup project build the next time you need to debug, so you should make sure the project gets built at least once.
PS. I initially tried the pre-build as suggested, but that didn't work (and I think it makes sense - if VS thinks a project doesn't need building, it won't execute any events for that project).