Related
In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?
What is the difference between Build Solution, Rebuild Solution, and Clean Solution in Visual Studio?
When is the appropriate time to use each one of these?
Build solution will perform an incremental build: if it doesn't think it needs to rebuild a project, it won't. It may also use partially-built bits of the project if they haven't changed (I don't know how far it takes this)
Rebuild solution will clean and then build the solution from scratch, ignoring anything it's done before. The difference between this and "Clean, followed by Build" is that Rebuild will clean-then-build each project, one at a time, rather than cleaning all and then building all.
Clean solution will remove the build artifacts from the previous build. If there are any other files in the build target directories (bin and obj) they may not be removed, but actual build artifacts are. I've seen behaviour for this vary - sometimes deleting fairly thoroughly and sometimes not - but I'll give VS the benefit of the doubt for the moment :)
(The links are to the devenv.exe command line switches, but they do the same as the menu items.)
Build solution: Compiles code files (DLL and EXE) which are changed.
Rebuild: Deletes all compiled files and compiles them again irrespective if the code has changed or not.
Clean solution: Deletes all compiled files (DLL and EXE file).
You can see this YouTube video (Visual Studio Build vs. Rebuild vs. Clean (C# interview questions with answers)) where I have demonstrated the differences and below are visual representations which will help you to analyze the same in more detail.
The difference between Rebuild vs. (Clean + Build), because there seems to be some confusion around this as well:
The difference is the way the build and clean sequence happens for every project. Let’s say your solution has two projects, “proj1” and “proj2”. If you do a rebuild it will take “proj1”, clean (delete) the compiled files for “proj1” and build it. After that it will take the second project “proj2”, clean compiled files for “proj2” and compile “proj2”.
But if you do a “clean” and build”, it will first delete all compiled files for “proj1” and “proj2” and then it will build “proj1” first followed by “proj2”.
Taken from this link:
Build means compile and link only the source files that have changed
since the last build, while Rebuild
means compile and link all source
files regardless of whether they
changed or not. Build is the normal
thing to do and is faster. Sometimes
the versions of project target
components can get out of sync and
rebuild is necessary to make the build
successful. In practice, you never
need to Clean.
Build Solution - Builds any assemblies which have changed files. If an assembly has no changes, it won't be re-built. Also will not delete any intermediate files.
Used most commonly.
Rebuild Solution - Rebuilds all assemblies regardless of changes but leaves intermediate files.
Used when you notice that Visual Studio didn't incorporate your changes in the latest assembly. Sometimes Visual Studio does make mistakes.
Clean Solution - Delete all intermediate files.
Used when all else fails and you need to clean everything up and start fresh.
I just think of Rebuild as performing the Clean first followed by the Build. Perhaps I am wrong ... comments?
Build solution will build any projects in the solution that have changed. Rebuild builds all projects no matter what, clean solution removes all temporary files ensuring that the next build is complete.
Build Solution - Build solution will build your application with building the number of projects which are having any file change. And it does not clear any existing binary files and just replacing updated assemblies in bin or obj folder.
Rebuild Solution - Rebuild solution will build your entire application with building all the projects are available in your solution with cleaning them. Before building it clears all the binary files from bin and obj folder.
Clean Solution - Clean solution is just clears all the binary files from bin and obj folder.
The one major thing I think people are leaving out is that Build and Clean are both tasks that are performed based on Visual Studio's knowledge of your Project/Solution. I see a lot of complaining that Clean doesn't work or leaves leftover files or is not trustworthy, when in fact, the reasons you say it isn't trustworthy actually makes it more trustworthy.
Clean will only remove (clean) files and/or directories that Visual Studio or the compiler themselves have in fact created. If you copy your own files or files/folder structures get created from an outside tool or source, then Visual Studio doesn't "know they exist" and therefore, should not touch them.
Can you imagine if the Clean operation basically performed a "del *.*" ? This could be catastrophic.
Build performs a compile on changed or necessary projects.
Rebuild performs a compile regardless of change or what's necessary.
Clean removes files/folders it has created in the past, but leaves anything that it didn't have anything to do with, initially.
I hope this elaborates a bit and helps.
I have a a blank solution BuildRebuildClean and three class library Models,Repository,Notification.
I use Models and Repository in Notification class library.
Then:
Build solution Incremental build and compiles only the files that are changed. If an assembly has no changes,
it won’t be re-built. Also, it will not delete any intermediate files.
If Modify some code in Models library project, then BUILD solution.
In the below screen shot, refer to the time stamp of DLL, EXE is updated in Models and Notification library.
Rebuild solution Deletes all compiled files and compiles all irrespective of changes,
ignoring anything it’s done before.
Right click on the solution name BuildRebuildClean. What it does is deletes all the assemblies,
EXEs and referred files to compile again.
Clean Solution Deletes all compiled, intermediate files (i.e., EXEs and DLLs) from the bin/obj directory.
All I know is a Clean does not do what "make clean" used to do - if I Clean a solution I would expect it delete obj and bin files/folders such that it builds like is was a fresh checkout of the source. In my experience though I often find times where a Clean and Build or Rebuild still produces strange errors on source that is known to compile and what is required is a manual deletion of the bin/obj folders, then it will build.
This is concerning "Build Solution" option only.
I got totally fed up with Visual Studio's inability to really clean solutions and wrote this little tool that will do it for you.
Close your solution in VS first and drag its folder from Windows Explorer into this app or into its icon. Depending on the setting at the bottom of its window, it can also remove additional stuff, that will help if you try to manually upload your solution to GitHub or share it with someone else:
In a nutshell, it will place all "Debug" folders, Intellisense, and other caches that can be rebuilt by VS into Recycle Bin for you.
Clean will clean the artifacts in bin/Debug folder. Means deletes all the files in bin/Debug folder.
Build checks the artifacts in bin/Debug folder and if required then creates the artifacts (while checking for build time errors).
Rebuild = Clean + Build in a single go. This will first delete all the files in bin/Debug folder and then create the artifacts again in the bin/Debug folder.
One can confirm these operations by opening and observing the bin/Debug (or Release) folder and then Cleaning, building and rebuilding the project.
**Build ,Rebuild, Clean Solution**
Clean Solution
: deletes all compiled files (all dll’s and exe’s ).
Build Solution
: compiles code files (dll and exe) that have changed.
Rebuild Solution
: Deletes all compiled files and Compiles them again regardless of whether or not the code has changed.
A two-part question ... but all answers (except from Justin Niessner) only focus on part 1: the difference. The second part is what I find more interesting: "When is the appropriate time to use each one of these?". But let me start with how I think of what each does:
Build: Should and usually does: generate (build) each intermediate and output file that is out-of-date with respect to its source files.
Rebuild: A workaround (hack) that allows you to build when the build command fails due to a bug with out-of-date evaluation.
Clean: A hacky implementation of deleting generated (intermediate and output) files so that a subsequent build might work. Hacky since it often doesn't delete enough. VS designers put all intermediate and output files in separate directories. Why not delete the directories?!?!?! But, I digress.
There is no clean/clear way to know when to use one command vs another. Knowing what each does, does not really inform me about the appropriate situation to use each.
It's more about personality than science. An optimist uses Build most of the time, but resorts to Rebuild if Build fails and they think the issue is wonky behavior of Visual Studio. And if Rebuild fails, then they do Clean and Build. When that fails, they start googling...
More pessimistic folks always use Rebuild since its more reliable even though takes longer when used every time. The most pessimistic always do Clean then Rebuild. They forgot there is a Build command. They also wear a belt and suspenders.
Some might think this is cynical. But, I think not. I think the UX of Visual Studio is bad and that users and the industry have gotten used to it. Worse, many other tools adopted the same UX since VS is ubiquitous.
IMO, Microsoft should: fix Build, fix Clean and eliminate Rebuild
Build solution only builds those projects which have changed in the solution, and does not effect assemblies that have not changed,
ReBuild first cleans, all the assemblies from the solution and then builds entire solution regardless of changes done.
Clean, simply cleans the solution.
I am trying to set up Xcode for a project which contains multiple executables and static libraries. I have created multiple targets and set up the linking and dependencies, and initially everything works great. The catch...
This is an existing project which already has Visual Studio and Makefile builds. Those builds put the libraries in a lib/Debug directory and the executables in bin/Debug. So in Xcode I changed the Build Products Path to "lib" and "bin" respectively (so we can use one set of documentation for all of the platforms). This puts the compiled targets in the right place, but completely breaks both the linking (Library not found) and the dependencies.
I can fix the linking by adding $(SRCROOT)/lib/Debug to the Library Search Paths for each executable (but it feels like Xcode should be able to figure this out on its own, which makes me think I'm doing something wrong).
But — I can't figure out how to get the dependencies working again. If I change a library source file, the library will rebuild but not the dependent executables. If I force a build of the executable Xcode returns success without doing anything; it thinks the target is up to date. If I clean the target and then rebuild it works.
So, any ideas here? Is Xcode being fundamentally stupid in this regard, or is it me (I'm leaning toward the latter)?
Update: I've posted a sample project to demonstrate the issue at http://share.industriousone.com/XcodeDepsIssue.zip. Build it once, then modify MyStaticLib.c and build it again. The executable will not relink (and it should). Many thanks for any help on this one.
starkos, thanks for publishing your conclusion. It validated my experience as well. This situation really screwed me, so it was nice to know I wasn't just missing something.
I did however discover a workaround that avoids creating multiple projects or keeping the library and its dependent in the same directory. It is a hack, but it does work here.
I know it's a bit late but better than never.
For the dependency library, add a "Copy Files Build Phase", with Absolute Path as the destination, and the path text field should be the directory where the DEPENDENT target lives. Then click on Products, find the dependency library (will end with .a), and drag it into the "Copy Files Build Phase." If you now build, this will put the library into its own directory like before and THEN also copy it into the dependent's target directory.
For the dependent, you can now remove the dependency's output directory from the Library Search Paths. This will cause it to find the library copy. If you do this, the dependent will indeed be relinked each time the dependency .a is relinked.
The negatives are, of course, the extra time for the copy, and the necessity to specify (in the Copy phase) the target directory for each dependent of your library. Beats the hell out of the alternatives though....
Xcode doesn't automatically set up dependencies based on use of build products; you have to set up explicit target dependencies yourself.
Project > Edit Target Settings, General tab, + button, add any targets that are prerequisites to building the selected target. That should get you going again.
I've researched this some more and the answer is no, Xcode 3.x doesn't track dependencies between targets that live in different directories. You can work around it by giving each library its own project, and adding each of those to a master project. Or you can keep all of your targets in one directory. Pick your poison.
Here is my solution for this weird behavior in xcode 4.3.1. You have to add build pre-action in scheme:
rm -f ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
and choose which build settings to use for this script. Each time before build, target executable will be removed and rebuild completely. It helped for me, and i hope it helps you.
NOTE: Have tried to put this script in project build phase, and result was negative - debugger could not connect process to start debugging.
Good luck!
OK, it would help to have the text of the Linking... build line that's failing. But a couple of things:
1) You shouldn't be linking to anything in $(SRCROOT). That's your project sources. The two places to find things to link are $(SYMROOT) (the Build Products directory) or $(DSTROOT) (the Installed Products directory).
One thing you could do is to have a common Build Directory, then use 'xcodebuild install' action to install the products in the Installation Directory. The other is to use a Copy Files build phase to copy them after building, so you can link against them in $(SYMROOT) but still have them where your Windows compatriots expect them.
THere is probably a way to set up the per-target build products directories correctly, but I'd really have to see the project itself to figure it out.
I have a C# project which includes one exe and 11 library files. The exe references all the libraries, and lib1 may reference lib2, lib3, lib4, etc.
If I make a change to a class in lib1 and built the solution, I assumed that only lib1 and the exe would need to be changed. However, all dll's and the exe are being built if I want to run the solution.
Is there a way that I can stop the dependencies from being built if they have not been changed?
Is the key this phrase? "However, all dll's and the exe are being built if I want to run the solution"
Visual Studio will always try to build everything when you run a single project, even if that project doesn't depend on everything. This choice can be changed, however. Go to Tools|Options|Projects and Solutions|Build and Run and check the box "Only build startup projects and dependencies on Run". Then when you hit F5, VS will only build your startup project and the DLLs it depends on.
I just "fixed" the same problem with my VS project. Visual Studio did always a rebuild, even if didn't change anything. My Solution: One cs-File had a future timestamp (Year 2015, this was my fault). I opened the file, saved it and my problem was solved!!!
I am not sure if there is a way to avoid dependencies from being built. You can find some info here like setting copylocal to false and putting the dlls in a common directory.
Optimizing Visual Studio solution build - where to put DLL files?
We had a similar problem at work. In post-build events we were manually embedding manifests into the outputs in the bin directory. Visual Studio was copying project references from the obj dir (which weren't modified). The timestamp difference triggered unnecessary rebuilds.
If your post-build events modify project outputs then either modify the outputs in the bin and obj dir OR copy the modified outputs in the bin dir on top of those in the obj dir.
You can uncheck the build option for specified projects in your Solution configuration:
(source: microsoft.com)
You can can create your own solution configurations to build specific project configurations...
(source: microsoft.com)
We actually had this problem on my current project, in our scenario even running unit tests (without any code changes) was causing a recompile. Check your build configuration's "Platform".
If you are using "Any CPU" then for some reason it rebuilds all projects regardless of changes. Try using processor specific builds, i.e. x86 or x64 (use the platform which is specific to the machine architecture of your machine). Worked for us for x86 builds.
(source: episerver.com)
Now, after I say this, some propeller-head is going to come along and contradict me, but there is no way to do what you want to do from Visual Studio. There is a way of doing it outside of VS, but first, I have a question:
Why on earth would you want to do this? Maybe you're trying to save CPU cycles, or save compile time, but if you do what you're suggesting you will suddenly find yourself in a marvelous position to shoot yourself in the foot. If you have a library 1 that depends upon library 2, and only library 2 changes, you may think you're OK to only build the changed library, but one of these days you are going to make a change to library 2 that will break library 1, and without a build of library 2 you will not catch it in the compilation. So in my humble opinion, DON'T DO IT.
The reason this won't work in VS2005 and 2008 is because VS uses MSBuild. MSBuild runs against project files, and it will examine the project's references and build all referenced projects first, if their source has changed, before building the target project. You can test this yourself by running MSBuild from the command line against one project that has not changed but with a referenced project that has changed. Example:
msbuild ClassLibrary4.csproj
where ClassLibrary4 has not changed, but it references ClassLibrary5, which has changed. MSBuild will build lib 5 first, before it builds 4, even though you didn't mention 5.
The only way to get around all these failsafes is to use the compiler directly instead of going through MSBuild. Ugly, ugly, but that's it. You will basically be reduced to re-implementing MSBuild in some form in order to do what you want to do.
It isn't worth it.
Check out the following site for more detailed information on when a project is built as well as the differences between build and rebuild.
I had this problem too, and noticed these warning messages when building on Windows 7 x64, VS2008 SP1:
cl : Command line warning D9038 : /ZI is not supported on this platform; enabling /Zi instead
cl : Command line warning D9007 : '/Gm' requires '/Zi'; option ignored
I changed my project properties to:
C/C++ -> General -> Debug Information Format = /Zi
C/C++ -> Code Generation -> Enable Minimal Build = No
After rebuilding I switched them both back and dependencies work fine again. But prior to that no amount of cleaning, rebuilding, or completely deleting the output directory would fix it.
I don't think there's away for you to do it out of the box in VS. You need this add-in
http://workspacewhiz.com/
It's not free but you can evaluate it before you buy.
Yes, exclude the non-changing bits from the solution. I say this with a caveat, as you can compile in a way where a change in build number for the changed lib can cause the non built pieces to break. This should not be the case, as long as you do not break interface, but it is quite common because most devs do not understand interface in the .NET world. It comes from not having to write IDL. :-)
As for X projcts in a solution, NO, you can't stop them from building, as the system sees a dependency has changed.
BTW, you should look at your project and figure out why your UI project (assume it is UI) references the same library as everything else. A good Dependency Model will show the class(es) that should be broken out as data objects or domain objects (I have made an assumption that the common dependency is some sort of data object or domain object, of course, but that is quite common). If the common dependency is not a domain/data object, then I would rethink my architecture in most cases. In general, you should be able to create a path from UI to data without common dependencies other than non-behavioral objects.
Not sure of an awesome way to handle this, but in the past if I had a project or two that kept getting rebuilt, and assuming I wouldn't be working in them, I would turn the build process off for them.
Right click on the sln, select configuration manager and uncheck the check boxes. Not perfect, but works when Visual Studio isn't behaving.
If you continue to experience this problem, it may be due to a missing or out of date calculated dependency (like a header) that is listed in your project, but does not exist.
This happens to me especially common after migrating to a new version (for example: from 2012 to 2013) because VS may have recalculated dependencies in the conversion, or you are migrating to a new location.
A quick check is to double-click every file in offending project from solution explorer. If you discover a file does not exist, that is your problem.
Failing a simple missing file: You may have a more complicated build date relationship between source and target. You can use a utility to find out what front-end test is triggering the build. To get that information you can enable verbose CPS logging. See: Andrew Arnott - Enable C++ and Javascript project system tracing (http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx). I use the DebugView option. Invaluable tool when you need it.
(this is a C# specific question, but a different post was merged as identical)
What are the *.FileListAbsolute.txt files for that Visual Studio generates? They keep cluttering up my searches. Such as when I search for *.csproj for adding projects to a .sln.
Does Visual Studio use them? Is there any way to make it not generate them?
The FileListAbsolute.txt file contains the list of files built in the current build and in prior builds, and is used during a Clean and Rebuild to figure out which files to delete.
The file is necessary because in certain situations, such as a project that has been renamed, you want the Build system to be able to delete the older name.
I know this is an older post...but I had this same issue and it turned out that I had accidently checked these into source control and not checked them back out, leaving them read only. The solution was to remove them from source control.
It tracks files to be deleted upon clean. From Understanding the Clean target:
[T]he common targets implement an honor-system method of tracking the output of "the last build". Well-behaved targets emit their outputs into an item named #(FileWrites), which is serialized to $(CleanFile) in the obj directory (it ends with .FileListAbsolute.txt) in a target named _CleanRecordFileWrites. Clean can then read that list and delete files in it during a subsequent MSBuild invocation.
Im not sure why it's generated and am researching that now. VS writes to these files each time you compile. You can delete all of them and it will regenerate when you compile. (Use caution if you use svn and don't delete the svnbase files)