I have a VS macro that I've been using for years to build my projects automatically. I'm currently trying out VS 2010 to see if I like it (my regular version is 2005), and one segment of the macro is not working in 2010. Well, rather, it will work ONCE on a given day, and then every time I run it after that, it fails. Here is the code:
With DTE.Solution
'Set the Build to "Release"
.SolutionBuild.SolutionConfigurations.Item("Release").Activate()
'Build solution
.SolutionBuild.Build(True)
'Set Build back to Debug
.SolutionBuild.SolutionConfigurations.Item("Debug").Activate()
End With
The line that fails is ".SolutionBuild.Build(True)". It simply doesn't Build the solution. There's no error. No indication that something is wrong. The code will run, but it just doesn't actually DO the build.
Does anyone have any idea why this would be happening?
My experience with it is that it does build.. if needed.
Try a Clean... if you want to rebuild every time.
DTE.Solution().SolutionBuild().Clean(True)
Related
Our WPF projects using Unity for DI do not seem to build correctly in Visual Studio 2019 unless we first do a solution clean, then a full solution build every time I want to run. I'd like to automate this, but it seems that VS2019 no longer has any sort of built-in macro support that I've found for doing this. Is there a way to do this natively? With an extension?
I've tried using the "Macros for Visual Studio" extension and recording these steps for playback, but that doesn't seem to get past the clean operation during playback. This is the macro I ended up with. I believe the issue is that it doesn't wait for one line to finish before the next starts, and I'm not sure how to make it wait in this extension, which has almost no documentation.
dte.ExecuteCommand("Build.CleanSolution");
dte.ExecuteCommand("Build.RebuildSolution");
dte.ExecuteCommand("Debug.Start");
I'm open to any solution that gets the job done.
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! 🤗
How can I make my code build to fail when ReSharper detects an "Error" after code inspection?
I am using C# in Visual Studio 2017 along with ReSharper. I have set the inspection severity of Possible 'System.NullReferenceException' to show as "Error". This setting only shows a red underline for erroneous code, however the VS build still succeeds if I just ignore it. I want to make the build to fail if developer ignores such errors detected by ReSharper inspection.
I'm afraid Resharper seems to not support this option for now.
1.In my opinion, the error level in C#\Potential Code Quality Issues is something like showing a red underline to indicate where there maybe has a risk to help improve your code. And red to indicate this issue deserves attention. Actually,it's something controlled by us, we determine to make them error(red line) or warning(blue line?).
But such a potential code issue can't be recognized by msbuild (build system in vs). So the build will ignore these potential issues and succeeds.
2.For build settings in Resharper, I tried msbuild settings and compiler settings like below:
I set every element in the Potential Code Quality Issues to error. Also, i set null reference related settings like below:
After that I create a simple null reference but the build ignores that and succeeds. Same result when I use Resharper build.(Resharper options=>Tools=>Build=>Build engine) So maybe it's a negative answer :(
This isn't an ideal solution, but JetBrains provide a command line tool called InspectCode which runs their code inspections on your solution and outputs the results in XML or other formats. You could add a custom MSBuild step which runs InspectCode.exe MySolution.sln -o=output.xml, examines output.xml for errors, and fails the build if any are found.
Unfortunately InspectCode is slow and even though the analyses seem to be cached across runs it still takes a significant amount of time. For example, on my solution of 700k lines of code the tool takes 60 seconds on the second run, i.e. with a warm cache. So I don't think this is a viable solution to run on developer machines on every build. It might be acceptable in an automated build system.
How can I figure out, how many files needs to be recompiled before I start the build process.
Sometimes I don't remember how many basic header files I changed so a Rebuild All would be better than a simple build. There seams to be no option for this, but IMHO it must be possible (f.e. XCode give me this information).
Update:
My problem is not, that Visual Studio doesn't know what to compile. I need to know how much it will compile so that I can decide if I can make a quick test with my new code or if I should write more code till I start the "expensive" build process. Or if my boss ask "When can I have the new build?" the best answer is not "It is done when it is done!".
It's really helpful when the IDE can say "compile 200 of 589 files" instead of "compile x,y, ..."
Could your version control tell you this? For example in Subversion "Check for modifications" will list everything changed since your last checkin (although not since your last build)
Mind you, doesn't "build" automatically do exactly that? (build only what's changed)?
Usually Visual Studio is good at knowing what needs to be compiled for you.
If you have multiple projects in a solution then just make sure your solution dependencies are set up correctly and it should just work when you hit Build.
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).