What should I do?
Basically, I want to commit my Visual Studio 2012 project, but it has a Debug folder in it that we traditionally don't commit. Only problem is that the Debug folder has the project's dll in it, and if I move the dll to the folder's parent, the project no longer compiles.
So here's the structure:
Project Folder > MSVC_2012 > Debug folder, sln file, etc.
And in that Debug folder is the dll. How do I move that out of the Debug folder into MSVC_2012?
Your question isn't entirely clear on details, but here are some options (and ways you could improve the question):
Your question looks like an XY problem. You stated that "if I move the dll to the folder's parent, the project no longer compiles." in which case the real problem here is why it isn't compiling. We'd need more details to figure out why. You also need to be clearer what you mean by "if I move the dll" - you can't "move" a DLL before it is compiled, and if you move it afterwards, then by definition the compiling worked, so actually your statement as it stands doesn't make sense. In any case, you should probably focus on fixing your broken build rather than fiddling with it to meet the needs of your version controlling.
You haven't specified why it is a problem for the DLL file to be in the Debug folder. I assume it's because you want to commit it to your VCS (which you didn't explicitly state as your goal). In which case, are you aware that it is not normal practice to commit the binary output of your code? So one solution might be to reconsider why you are trying to commit the DLL in the first place.
You didn't specify which VCS you're using. In Git (and I assume in most other VCS') you can have finer grain control over what to exclude from commits than whole folders. So, another option is to configure your VCS to ignore the Debug folder with the exception of any DLL files contained inside it.
You can change where MSVC places your DLL file in the project property pages under Configuration Properties -> General -> Output Directory. Presumably this is what you meant when you referred to "moving" the DLL?
Finally, as per other people's comments on your question, if you want the DLL to be in both places you can use a post-build step to copy it to the relevant place. To achieve this go to the project property pages under Configuration Properties -> Build Events -> Post-Build Event then enter the relevant command (the same as you would type at a command prompt) to do the copying e.g. copy myfile.dll .., or as Alex Farber suggests, use VS macros to specify the locations in a more generalised way. See this page for a list of available macros that you can insert into the command. This should be considered a last resort solution for two reasons - (a) it is a hack, as you are redundantly copying a binary output to circumvent a shortcoming in your version controlling and/or build, when you should fix the problem at root, and (b) build events have a serious flaw in them in Visual Studio and that is that they don't allow values to be inherited. This makes them a maintenance nightmare in bigger projects.
Related
I'm on a BizTalk 2013 solution and I'm trying to grow into automated testing. However, when I try to run my tests after changing only the test project, or even just run the tests after changing nothing anywhere, I'm stuck building the same amount of projects that I build when I invoke a full rebuild on the project being tested. This eats up an enormous amount of time, and it's a death sentence for my ability to sell future investments into this type of thing.
Is this is a known deficiency with BizTalk, or with its interaction with MSBuild? Is it a known pitfall that I can repair on my end?
EDIT: After reviewing the "possible duplicate" thread, I believe this question to be similar, but distinct. The explanation from the thread highlights the mechanics by which MSBuild determines that a rebuild is necessary, but MSBuild is widely-used technology across all projects in Visual Studio and can differ significantly by project type based on that project type's specific targets import. I've edited the question title to reflect that I want to learn how to prevent this for BizTalk solutions rather than simply asking why it's happening (although knowing why is always helpful).
So, what you're seeing is not a problem with BizTalk (because BizTalk is perfect and wonderful and never has any problems ever...:).
It's actually a behavior of Visual Studio. To note, BizTalk Projects are just specialized c# Projects.
The best workaround, which I do all the time, is to uncheck the Build and Deploy options for Projects I'm not actively working with in the Solution Configuration. If the Project is not checked for Build, it will not build even when you choose Rebuild Solution.
One possible solution would be to reference not the projects, but the DLL files which are the result of the same - already compiled and built - projects.
This way, when building your test project, it would be built against these existing assemblies and hence would not take the time to rebuild those.
You have to make sure however that these DLLs are updated whenever the project behind them also updates. You could do this by rebuilding them, whenever necessary, in a separate Visual Studio instance.
It takes some practice and thinking to make sure you are building against the latest version, but it WILL save you a lot of time.
I've noticed this as well. Turning on diagnostic output on MSBuild, it turned out that the project settings .user files were being modified after the .pdb files. I've tried several ways of resolving this, including changing the modify date on the pdb file, setting the .user file to readonly, removing (renaming) the .user file, etc.
Unfortunately, the build task for BizTalk will overwrite/recreate/create new .user file after every build, and I haven't come up with a way to convince MSBuild that that it can just ignore the .user file being created as new. Due to that, I'd go with one of the other suggestions here.
Even creating an exclusive lock on the file so that MSBuild can't update it causes a rebuild, since then MSBuild thinks the build is dirty ("Project 'Schemas' is not up to date. Project dirty in MSBuild.")
I have a C/C++ solution comprised of several projects in VS2010. The start-up project is where main() locates and it will generate .exe file, while the others are core algorithms which will generate .dll files. When I debug the whole solution, sometimes it cannot go into the .dll projects but after rebuilding the whole solution, the problem can be temporarily solved; However after building one or more times, the problem returns.
Currently I have to rebuild the whole solution every time I modify the code, but it's so bothering. Is there any way that I can avoid such a problem?
It is happening only in the case when some project in your solution is changed or the .exe present in release or debug directory is different from the code. So, make sure like you are building each project successfully after modifying it.
And it is always good to debug in DEBUG mode to get exact result.
Everal things you could try: Make sure all projects which need to be rebuilt after a change indeed are. So make sure the project dependencies are set correctly and that the startup project is the exe project.
As second option, you could allow the debugger to show source even if it does not match the code exactly (look for something named "source files must match original exactly" or similar in Options->Debugging->General). Be aware that it might indeed happen that your changes are not reflected in the program if this is needed.
So I have main.cpp and main2.cpp with int main in each. I want to get 2 exes out of it. Is it possible and what would be instruction to create such project?
Nope, Visual Studio's project model is rigidly built around the assumption that "one project generates one output".
If you need two executables, you have to create two projects. You can keep them in the same solution to make things easier for yourself, but they have to be separate projects.
Edit
Ok, as other answers have pointed out, it can of course be done, if you're desperate. You can add a custom build step, which does anything you like, including building another executable. (However, the build system won't understand that this file should be considered project output, and so some scenarios may fail: for example the file won't be automatically copied to the output folder, and when checking dependencies before a rebuild, it might not be able to understand which files to check, and what (or how) to rebuild.)
Visual Studio (at least up to 2008, not sure about 2010) also allows the use of nmake files, but then I think you're stretching the definition of "a Visual Studio project".
But under "normal" circumstances, one project implies one output. And in order to get two executables, you'd normally create two projects.
You need a solution which includes two projects. Have a read of the Visual Studio documentation on solutions and projects.
Here's my solution, since nobody in a Google search seems to suggest this method. It's quite simple and I've used/seen it used in other IDEs (like Code::Blocks).
Within your project, create a configuration for each output that you want. Then, only include one main source file in each configuration.
In VS, this means for each source file with main: right-click -> Properties -> Excluded From Build = Yes. So, once you're done, only one main source is built for each configuration. You can then specify a different output for each configuration in the Project Properties. I did this on VS 2010, but it should probably work with other versions.
I'm using this approach so that I can have several tests for one project, without cluttering the solution with more test projects than actual code projects.
I don't know if it can be done ,but the only change you have ,to do this ,is with custom build step.
EDIT: Since someone downvoted this ,i did a test making a dummy configuration.
In the custom build step I two Link-cmds (copied form original link-cmdline and modified it a bit) taking as input main1.obj resp. main2.obj and outputting App1.exe resp. App2.exe.
It's executed after Compiling and before linking.
It worked !
The downside is I cannot prevent (yet) the linking ot the orinal exe (which errors on duplicate main function).
Solution to this could be to have a lib project excluding the sources with main()from build and build them in the custum-step too.
So the answer to the question should : Yes ,it can be done!
You can't have more than one main() function in a single visual studio project. So you can't compile 2 executables, the only way is to make two different project in the same solution
You can create a solution with two project one for each output you want. Then head to Build menu and select Batch Build.. and select both projects.
If you want both exe files to be in one place you can specify a custom Post-build action:
For both project:
view the project properties page and in Build events select Post-Build events, then in the Command line field enter the command that will copy the output to the location you want, something like:
copy $(TargetPath) c:\yourlocation /Y
Then after you build the solution the output files will be copied to that location.
Another option you have is to use conditional compilation with sth like
main()
{
#ifdef VERSION1
call_main_logic();
#else
call_main2_logic();
#endif
}
and then define different configurations within the project. For each configuration you will then need to define preprocessor symbols appropriately (in: project settings -> configuration properties -> C/C++ -> preprocessor).
Please note, that it will be only one executable created at a time, but with switching configurations you'll get the one that does what you want at the moment.
... which may suit your needs or not, depending on more specific situation that you are in.
Edit: In addition, since different configurations create their separate output folders, you will have your both execs as outputs.
Is it possible to combine the following properties, and if so, how?
Store in our version control system some Visual Studio 2008 native C++ (VCPROJ) project files for the developers in our team that use this IDE.
Allow some of those developers to tweak their projects (e.g. using debug version of third-party libraries instead of the usual ones).
Make sure these modifications are done in files that are not versioned.
In other words, I would like to allow developers to tweak some settings in their projects without risking that these changes are committed.
An 'optional VSPROP' file approach seems doomed to fail, as VS2008 refuses to load projects that refer to non-existent VSPROP files...
Any other suggestion? Is this possible with VS2010?
You may not be able to do this but using a solution that generates the vcproj like CMake for example would let you do this. Scripts all your project with CMake and literally conditionally include a config file(if present for example) that developers can change on their setup.
Branches could solve this problem: you create a branch, play with different versions of third-party, merge changes to trunk if results are good.
Well, as a preliminary solution you could put the project file into something like .hgignore or .gitignore after its initial commit.
This way changes to it can't be done accidentally.
At least that's how I handle .hgignore itself.
We use a versionned "common_configuration" folder, and a script which copies project files from this "common_configuration" folder towards the "project" folder.
We have another script to copy the configuration backwards, so the developpers need to make a conscious action to commit their local changes to the global version control system.
It answers partly your needs :
The upside : we have a way to keep a common configuration for everyone, and no accidental committing of local configuration
The downside : blindly copying the files actually crushes local changes. We live with it. We could write some more clever merger tool (using diff, or xml specific manipulations), but don't want to spend to much time on supporting the deployment tools.
I am creating a simple C++ DLL project using Visual Studio 2008 Express Edition.
I have a few classes inside a namespace, and a few non-static functions and constructors inside it are declared with __declspec(dllexport).
All those functions are implemented.
I also have an extern "C" BOOL APIENTRY DllMain function which simply returns TRUE.
As I hit Debug(or Release), it successfully builds with no errors nor warnings.
The output folder(either "Debug/" or "Release/") gets files such as "BuildLog.htm", one ".obj" file per source file, "vc90.pdb", "vc90.idb", "[DLLNAME].dll.embed.manifest", "[DLLNAME].dll.embed.manifest.res", "[DLLNAME].dll.intermediate.manifest" but... not the DLL itself.
This is the first time I try to compile this project(so I never sucessfully compiled before) and I have little experience with C++/DLLs, although I do know standalone C++ and created Linux C shared objects before.
What am I doing wrong? Is there any particular required file that I'm missing?
I'd look up a little higher in the directory structure (the one that the solution is in) and see if your Debug/Release folders (with the DLL) are there.
I think the default is to put the actual DLLs in folders in the solution directory, not the project directory (I think the assumption is that you want all the DLLs that you build for a solution to go to the same place)
Right click on <ProjectsName> in Solution Explorer View, select Properties, go to Configuration Properties > General tab and check out the Output Directory field. The path may consist of some macros like $(SolutionDir)$(ConfigurationName) etc. Click on it, select Edit and then when a window pops up choose Macros to see what they actually mean e.g. which directory SolutionDir maps to. You can deduce the output dll's path from there.