I usually format my project directory like J-P Boodhoo. a main dir containing solution file, then a lib folder for all third-party lib, a src dir, a tools lib for third-party that wont be deployed.... For more info look here
I set in my project the reference path for all the needed folder, but if a developper checkout the trunk, he have to set all the reference path. Is there a way to simplify this ?
And am I using Visual Studio 2008.
Thank you.
I'm not sure which Visual Studio language you use, but if it's C++, then then file paths are stored in the .vcproj project file which should also be under version control. (NOTE: the .sln solution file does NOT store path settings) If you are careful to use relative, rather than absolute paths, it should be easily sharable among multiple developers.
In Visual C++ 2008, project files are XML so you can edit them directly. If you want to get really fancy, you can use .vsprops property sheets for additional control.
I use a shared folder on the network for stuff like that. And give that folder full trust. on the PDC i just have a login script that maps approriately. Its might not be the best way, but its worked for me without any issues.
Another solution I have used in the past is a common folder on each machine where all dependancies go, and have it syncronize with some sort of tool. I use Backup Exec which comes with Desktop and Laptop option which has a syncing feature, but other things work as well.
Related
I'm working on a project with Qt using the Visual Studio Addin in VS2010 Professional. Two branches of the project use two different Qt versions (4.8.4 and 5.0.2) so I have both versions of the addin installed (1.1.11 and 1.2.1). I'm also actively developing using at least two computers, both Windows 7, for which I have a networked, roaming user profile. I don't know the specifics of how this user account or network is setup.
Qt is installed in different locations on each system. If I set the correct paths in the Addin on one system (System A), it changes them for the other system (System B) and then complains to me that Qt doesn't exist at that directory when I later log into System B. Is there a way to save the paths to Qt versions on the system, without it affecting the paths on the other system? Or will I have to just deal with changing them each time I change computers?
EDIT:
I from looking through the source for the visual studio add-in, I found that these settings are saved as user registry values. I don't know much about Windows roaming profiles but I'm now assuming that user registry values are copied between computers just as their files are. I don't know if there's any way to move these registry values somewhere else without having to edit and recompile the add-in. I suppose the only other thing I could do is write a startup script to edit these settings upon login.
EDIT: Make sure visual studio on each computer can find the right add-in and the right environment variables on the computer you are using.
http://qt-project.org/wiki/QtVSAddin
In this documentation it talks about where it gets installed to:
"%USERPROFILE%\Documents\Visual Studio 2008\Addins"
So you could manually change the location of the addin, to some local system path.
How to -> Visual Studio Add In Manager
Or you could change the qt path that the Add-in refers to every time you log in, or right before opening visual studio.
Setting a system environment variable from a Windows batch file?
I would use version control to just get the files that you need for the project, and exclude/ignore all the environment specific elements of the project.
One way you could achieve this is:
To install Bazaar. Create a standalone tree of the code on a shared drive or on a location on the harddrive that both users have access to.
Do an initial add of all your source and header files and your qt .pro file.
Checkout or branch the code to user specific folders. In those user specific folders, let Visual Studio create all the user specific, Qt Add-on specific, (etc) files.
Also create a .bzrignore file with files and folders like these listed:
Debug
Release
x64
*.ncb
*.suo
*.user
*.vssscc
*.scc
*.vspscc
*.lnk
*.bak
*.aps
*.pro.user
object_script.*
Makefile
Makefile.Release
Makefile.Debug
Then when you want to try your build for each setup, finish your edits, commit/push your changes on the user that did the edits, and update/pull on the user that wants the changes.
Although the version control may be a little tricky to get started with, it will make project collaboration both scalable, trackable, and very manageable!
And you aren't limited to Bazaar. Check this wiki out if you need ideas.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Another way that you could try to go about doing this, is to have all the source code in some path (either absolute or relatively up from your projects locations), or on the computer, and have the project folders reference those paths in the project folders, but have two separate project folders. This would not be nearly as elegant, but would work.
C:/path/to/vs_proj1
C:/path/to/vs_proj2
C:/path/other/proj/source
And in the properties for vs_proj1, and vs_proj2, in the part about locating source files, have ../other/proj/source to find it relatively, or put the absolute path C:/path/other/proj/source.
Also two other things to be aware of when sharing projects over a drive like this, is that when you are referencing libraries, you may want to store that information in a user specific macro file in Visual Studio and reference the macro in your project settings.
Visual Studio - Where to define custom path macros?
And while I'm here, you may need to #define some things in your program to allow for behavior for one version of Qt that isn't in the other.
So for example, in the source of your program, you might have:
#if QT_VERSION < 0x050000
// some Qt 4.x specific stuff, not in Qt 5
#else
// some Qt 5 specific stuff, not in Qt 4.x
#endif
Hope that helps.
I'm not using the default Visual Studio project path to build my program into, because I want to emulate a release, and write tools to search for resources. After tinkering with the settings, I've got VS to output to the right folder, and to copy the DLLs to a bin folder in the main folder. However, I can't get the .EXE it generates to find the DLLs, it will only find what's in it's directory, but I don't want to be messy like that. The debugger works fine, but it won't work standalone. How do I tell VS to tell the .EXE where to find it's DLLs? Do I have to edit the PATH? That seems messy, as I've never had good experiences with it. I've tried Project Settings -> VC++ Directories, but it still won't find it, as I'm assuming that that's for .LIB files.
Here is a diagram of my folder hierarchy.
-root
--bin
---[Required DLLs]
--data
---[Program Resources (images, sounds, configs, etc.)]
--Program.exe
Using Visual C++ 2010 Express Edition.
How do I tell VS to tell the .EXE where to find it's DLLs?
Edit the Release Run Configuration and change the working directory where your dlls reside.
You will still have to run your exe through the ide for this to work.
Do I have to edit the PATH?
No
This doesn't have anything to do with Visual Studio. It is Windows that can't find the DLL. It has no reason to look in an arbitrary subdirectory for a DLL. It isn't otherwise clear whether these are implicitly loaded DLLs or if you use LoadLibrary to load them yourself.
You don't have much of a problem if you use LoadLibrary(), just pass the full path name of the DLL. GetModuleFileName(NULL, ...) helps you build the path string. You'll have a Big Problem if these are implicitly loaded. In that case, there should be preciously few reasons to not store the DLLs in the same directory as the EXE. And yes, you don't want to mess with the PATH environment variable. Or the current working directory.
I am the only developer for an application. All the files for this application are stored on the same computer and I am using Visual Studio 2010 Ultimate.
The application has three solutions and these share common items such as some stylesheets, some javascript and shared views.
It's starting to become difficult when I change one file as I have to copy this to the other projects in the other solutions.
Is there a simple way that I could share files. Something that would help me be more productive. Possibly even some single user source code or a way of linking files between solutions.
Hope I can find someone to help me make my life easier.
Robert W
Even if you work on your own I would suggest some kind of Source Control System. Team Server is now free with Visual Studio or you can use open source tools. Like this you can link to source files in other projects and you can reuse your files.
Use Source Control! SVN is free so is TFS with Ultimate.
If its web based files (javscript, pictures, css, etc) use a virtual directory to point to the common code directories.
if its compiled code (C#,VB, etc) you can link the files. When adding an existing file in the dialog it will have a open button, with an arrow down. click the arrow down and "add as link" will be available. It will then use relative referencing to the other file. I use this technique for a SolutionAssemblyInfo.cs file.
I would recommend placing the common files in the same directory as the solution file or no more than 1 folder deep.
I have a folder on my hard drive, C:\Program Files\Microsoft SDKs, and I was wondering if it is safe to move it to an external drive. Does Visual Studio or any other tool depend on this particular folder?
There are quite a number of entries in the registry (at least in my registry) that point to that location, so it seems something would work in a less than optimal fashion. At a minimum, it would make the uninstaller a bit confused. It is probably safe to simply rename the directory temporarily and try your builds to see if they still work. Ultimately, though, it seems it would be cleanest to run the installation again to actually remove it and then install to a new location.
Yes. Most Unmanaged code in VSStudio refer to certain include files present in the include folder.
Also some exes in bin folder are also referred to (especially VS2008).
VS2005 refers to an internal Platform SDK location.
VS2008 refers to C:\Program Files\Microsoft SDKs\Windows\v6.0A
However most projects refer to this location via a macro. So if you can find a way to update the macro with the new location, then you should be fine.
Doing this may break some of your applications. If you added a reference to a project by browsing to a DLL installed in this folder, that project will not compile after you move this folder. If you haven't added any references in this manner, you might be OK.
As an example, I'm trying to add a reference to WatiN in Visual Studio 2008. I download WatiN and I have a folder on my desktop containing 5 files:
WatiN.Core.dll
WatiN.Core.xml
Interop.SHDocVw.dll
Microsoft.mshtml.dll
WatiN.Core.UnitTests.dll
WatiN.Core.UnitTests.dll.config
I can add my reference to WatiN.Core.dll and start coding in Visual Studio. But I have some questions:
Can I now delete the folder on my desktop? Were the files copied to the project bin?
What happens when I check my project into source code and another developer checks it out? Does he/she have to have the same folder on their desktop.
My thought was to create a lib folder in the project and reference the files in the lib folder. This folder will get added to source control so that everything should work for the next developer. But I have some questions about this solution:
Do I need all 6 of those files?
I believe the .config files have something to do with intellisense, but the project will build and run without them right?
How do I know what files to include apart from the WatiN.Core.dll. The project builds and runs with only WatiN.Core.dll and Interop.SHDocVw.dll. How am I meant to know what the dependencies are?
Any insight is much appreciated.
Adding a reference does just that. It adds a reference, so if the reference is to your desktop folder other developers will not be able to see the files. Also, if you delete the files you will have dangling references in your project. In general, don't reference files on your desktop.
Making a lib folder in the same source control tree as the project as you have suggested is a much better solution. Visual Studio will store the references as relative paths enabling other developers to compile the project.
You will have to study the documentation for the WatiN library to know which files are required by your application. You should not delete the .config file as it is not related to intellisense.
I would create a developement tree with all source files, library files, tools, docs, resources so that any developer can get a working project straight from source control without having to search for references.
Having referenced DLLs in a lib folder means that projectA is able to use version 1.0 of the DLL and projectB is able to user version 2.0 of the DLL.
When the solution builds it will get the DLLs from where they are referenced. If it cant find them the project wont build.
Have a look at the following articles.
http://www.codeplex.com/treesurgeon
As for which dlls you need to reference, you can go the way of only referencing what you need.
WATiN needs the WATiN.Core.dll and the Interop.SHDocVw.dll in order to run. As others have suggested, it's best to have a lib folder in your source control tree for external libraries so everyone can use relative references.
TreeSurgeon, mentioned above, is a good tool or you can at least use their folder structure as a model.
The Watin.Core.xml file should give you intellisense if you put it in the bin with the dll.
I believe you can only delete the folder if you are referencing the file directly from the bin folder (cut and pasted it there). If you are referencing the file from the folder than I believe you need to keep it there.
You may run into problems deleting the other files if the dll your referencing, references the classes in the other dll's.