The Pre/Post Build Events in Visual Studio has bugged me for a few years, but I just haven't got around to research a better alternative. The thing that I want to achieve is pretty much the same as I get with Post Build Events: I call a piece of code that does something before or after a project build.
The two things with the Pre/Post Build Events that really bugs me is that (1) the code is separated from my project and compiled into a command line .exe and (2) that every error I get will end up as a cryptical message in the error pane.
I would ideally want to write a static method inside my project that gets called before or after the project builds and if an exception pops up, it gets stack traced like any other exception in debug mode.
What existing (simple) approach can I use to get something like this done?
Related
I have a .NET Core 2.1 solution containing 2 F# projects, one class library and one executable. When I run the executable project with the command:
dotnet run --project ServerProject
it shows the Suave.IO log message immediately:
Smooth! Suave listener started in 92.632ms with binding 0.0.0.0:3000
However when I try to debug in Visual Studio (2017 or 2019 Preview) nothing appears on the dotnet.exe window at all — unless I pause debugging and continue, at which point it will carry on as usual and display the log message immediately.
I have set breakpoints to try and figure out where it gets stuck but nothing special happens there at all. My code loads some data from a CSV and it somehow gets stuck at the stage where it converts the CSV's rows into some records. All breakpoints and printf statements before this function get hit but the subsequent ones don't. And every time I pause debugging it seems to pause at a different point of this cell parsing code, so it's not even hanging in the exact same place every time.
I'm fairly new to the .NET world so I'm not even sure where to start investigating. Any help would be appreciated!
EDIT:
Adding this to say that this has been happening consistently for many months now. Any ideas would be really appreciated.
I'm trying to develop my first custom SSIS task. I've got two instances of SSDT open -- one for building and debugging the task, and the other that uses the custom task. Then in the first instance, I use the Attach to Process function from the Debug menu to debug the code. That all works fine but my trouble is that each time I rebuild the task and register it in the GAC from the first instance, I have to close and reopen the second instance of SSDT. If I don't, the second instance seems to still use the previous build of my custom task. Is there some way besides closing/reopening Data Tools that will cause it to recognize the new build of the custom task? All the closing/reopening is getting exhausting.
While it has been a decade since I last built any custom components for SSIS, the work cycle is as you describe it.
The best bit of of advice I'd offer is to add post-build steps to your development process to GAC the DLL. Oh, and modify your Visual Studio shortcut to include /nosplash to eliminate the startup splash screen.
Most of the time, when I build my project, I'm able to attach to breakpoints and debug, as I should. However, sometimes after building, I still get the error “The breakpoint will not currently be hit. The source code is different from the original version.” No matter how many times I build and rebuild it doesn't change it, until seemingly randomly it decides to behave and start working again. How can I fix this when it happens?
Edit: My builds are fine, there are no errors in my builds.
A wild guess...
In "Solution Property Pages" -> "Project Dependencies", choose the project and make sure the dependencies are defined well; for example: if you are using a web service in another project in the same solution, you should make the project including the web service depending on your project or you will not be able to debug the web service.
Of course, I don't know how this option may be bypassed as you say it happens to you randomly.
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.
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).