I have a solution that I would like to run each day, but simultaneously continue development on it. While it is running, when I attempt to build a new version I receive the error that "Unable to copy file "obj\x86\Debug\Solution.exe" to "bin\Debug\Solution.exe". The process cannot access the file . . . ". This is perfectly understandable: the currently running version has a lock on the .exe, so a new one cannot be created.
My question is this: what is the best practice to "release" the current version to run each day, while keeping a separate "debug" version available for development? My current approach is to create a separate copy of the project, but that is very tedious. Is there a better way?
Thank you,
Ben.
Build a Release Version, run it from folder. (Set Solution Configuration to Release)
Develop and debug in debug mode.
Assuming this is a Winforms or WPF app you can right click on your project, click on Properties and go to Publish tab. From there you can publish your app to a UNC path, install from there and run it while continuing development from within the Visual Studio IDE.
Edit: Additional advantage of this approach is that when you have a new version you will be able to publish to the same location and the next time you start your app it will be automatically updated.
Are you using any source control system? It's not clear if your problem is simply the mechanics of making a build, or how to keep a copy of your source that corresponds to each build. If the answer is b, then a source control system is designed to solve this problem.
You would make a build each day and publish/release the binaries, while at the same time checking in your source code. That way you have a "copy" of your source code that corresponds to each released build, while still allowing you to continue active development.
I would use a post-build script to simply copy the resulting EXE to a new location. You can run it from there easy enough. You can even execute it in the script if you don't like double-clicking ;)
Related
I've googled pretty much but i can't seem to find any information on this..
I've cloned a project from github, it opens and builds no problem. it's also added to my start menu.
I can run the program from my start menu as if it was a "normal" program.
Now I have made some changes to the sources and built it, and the changes seem to be present in the installed version (which I start from start menu) just by themselves.
my question is: is that really the case? do UWP apps get installed and updated automatically? is there a way to NOT update my installed version with my release-build every time? it seems wrong, did I miss something? (did I maybe "install" the changes somewhere along the way without noticing/by double-clicking the executable etc.) and: can I replace the executable that is started in the start menu? I tried to find where it is stored/linked, but I couldn't find anything, as there is zero information in the start menu.
Or can I rely on the start menu version always being my latest release build?
I'm confused, if someone has any information on this, I'd be really happy. :)
You are correct whenever you build and run the app on the local machine using Visual Studio it gets deployed to the system apps from where you can run it. So each time you build and run with any changes they will be updated in the system installed app as well(Basically they are same)
If you want that these changes do not get reflected in the system's app then I think you can use Device emulators available in the Visual Studio.
The developers in the team often forget to switch to Release mode, so we often end up building in the wrong mode (Debug) -- taking a long time.
Really need to set the default build to Release.
After some simple testing, I believe VS2008 follows this rule:
if a solution was in Release mode when the developer last closed it,
then the next reopen would be in Release.
if a solution was in Debug
mode when the developer last closed it, then the next reopen would be
in Debug.
The last-used mode seems to be saved in the local *.suo file, and unrelated to the *.suo file on another developer's code directory.
If that's the case, is there something we can do in the code repository to set the solution to "always start in Release, unconditionally"? Perhaps check in the binary *.suo file but not a best practice.
under solution select properties and go to configuration and change it from debug to release:
If you need to create a Release build to move to production, the ideal solution is to set up a build server to handle it. But either from a dev box or a server, you can create a batch file to compile a Release version of your code. This way you always get the correct build, regardless of what an individual developer has set on their box.
I often need to return to a previous milestone.
There is a vicious cycle: my error is revealed only during debugging, but I can't step back because the debugger has saved my project.
In simple projects I always used to make a copy of my cpp file (just keep ctrl and drug your file a bit).
But now projects has become more complicated (with header files).
I have tried to use save solution as. But it seems as if it is just renaming the sln file without making a copy of the whole project.
So, what shall I do? Copy the whole project as I did with the file?
The question seems a bit clumsy but it really troubles me: what elegant decision is there?
You can use software versioning systems like SVN or Git to undo the savings and return to previous point in your project, also there are some extensions for visual studio like ankhsvn and Gitextention that you can use.
If you are using vs 2010, you can disable saving on build event from Tools>Options>Projects and Solutions>Build and Run
I'm trying to build a publish script that doesn't use VS2010 -- I want it to be automated and in powershell (may use Psake soon). The biggest issue that I run into is that a project that will build and publish fine in VS2010 will either not build or not publish via the msbuild command. The closest I can get is (anonymized code):
msbuild /p:OutDir=c:\temp\publish\staging\myProj\myProj_1481\;Configuration=Debug;UseWPP_CopyWebApplication=True;PipelineDependsOnBuild=False C:\TEMP\export\myProj\1481\src\myProj.com\myProj.csproj
That one is failing for a Could not find file error in one of the DLLs. Naturally it publishes fine from VS2010. Is there some sort of recursion that I need to do? I'm burning up quite a bit of time on this one particular portion of my script -- the one part I have the least control over.
Requirements:
if the proj will build in VS2010 I shouldn't need to modify the csproj file -- I don't want to hand this script off to someone else and have them stick in "fix your csproj" land for hours per project
have to be able to script it entirely at the command line
hopefully no additional installs needed
Related:
Trying to Build and Publish Asp.net website from command line using aspnet_compiler (old)
_CopyWebApplication with web.config transformations (didn't fix my issue)
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).