Iam trying to share a DLL file between three Solutions. The idea is to maintain only one dll. If one of the programs is starting it will use this shared dll.
I know there is a "local copy" switch but the result of "False" is, that the program is looking for the file in its own folder instead of using the Path of the reference.
Or is there another way of sharing the Form without maintaining every single Form on its own?
Thank You
Related
I am wanting to setup a project and potentially an existing project to be SVN version controlled. I am using uberSVN for the svn server. I have installed AnkhSVN for visual studio.
Currently, the team I am working with is using visual source safe and one of the problems we have is when someone adds a reference to a DLL, it modifies the project file as you would expect, but our paths are different between different team members (XP boxes, 7, you get the idea). What I was wanting is making the project file ignored when checking in/out so that we don't mess up the references for everyone else.
Is there a way I can make SVN ignore these files within the plugin? One of the side effects of this is a person would not know if a new file has been added in the project as this modifies the project file. Other than telling everyone "hey, you need to manually add this file to your project," is there a cleaner way of doing it?
If you copy the DLL to a folder inside your VS solution folder before linking to it, I think the project link will be relative not absolute. So you can check the DLL and the updated VS project into your configuration management and everyone should be able to share it.
You should start using virtual paths for development work; that way each team member can keep work-related files at any physical location but the virtual path (the one seen by tools is always the same.
For example, my team does all work under Q:\. My physical source for work is under physical path C:\Work\<project_name> where the project_name part depends on the project. When I want to work on a given project, I map the Q:\ virtual path to the right physical path using
subst q: c:\work\project_name
When I need to switch, I run a similar command. This way there's no need to worry about different paths on different computers. This worked very well for the whole team and eliminated most issues you describe above. The only thing you need to make sure is that everyone always uses the virtual path (Q:), not the physical path when dealing with project-related files. For my team it took about a week to get used to that, after that there were no more problems.
Your project file is an important part of your project so ignoring it in the source control tool will eventually lead to problems. I recommend you don't do it (even if you can).
Edit:
If you have DLL-s in different physical folders on different machines, the best choice is to copy those DLL-s (and their dependencies) to a known location. It's fine that they can't run from there, as long as the compiler finds them.
This known location could be inside your virtual path or a common physical path (if the same DLL-s are needed for multiple projects). You can use Dependency Walker to determine what dependencies you need for native DLL-s and Reflector for .NET DLL-s.
If the size/number of DLL-s is so large that creating a copy is not an option, you can actually tell AnkhSVN to ignore certain versioned files when committing changes. Right-click the file, select Subversion > Move to Change List > ignore-on-commit. After this the file will show up in the commit dialog unselected but you can still commit it if you manually select it.
I'm looking for general advice. I created a Visual Studio 2010 project that outputs an ocx file that is used on XP and Vista machines. The DLL on which it depends has been updated on our Win7 machines. I simply needed to rebuild for Win7 using the exact same code with an updated .lib file. I created a second project configuration (ReleaseW7) and it only differs from the original project config (Release) in that it points to the new .lib.
So now I have 2 files both named xx.ocx. Besides looking at the name of the folder each file resides in (or looking at the creation time of each) there is no way to determine which is which. I thought of using different file version numbers but as far as I can tell (and I'm relatively new to this so I could certainly be wrong) that would require two separate projects each with a slightly modified resource (.rc) file, instead of simply having two configurations within the same project. If nothing more, that seems like a waste of hard drive space. It also feels like the "wrong" way of using file version numbers
Is there a cleaner or more "standard" way of handling this? All I really want is a way for the folks who install the ocx and support the end user to know for certain that they are working with the correct file.
Long story short, I decided to use different version numbers. I was able to setup a preprocessor definition for the resource compiler and use that to handle different versions of VS_VERSION_INFO in my .rc file.
In case anyone is interested, this is the resource I found:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/605275c0-3001-45d2-b6c1-652326ca5340/
I am currently working on several applications and in n some of these apps the solutions contain projects from multiple work spaces in Visual Studio 2010.
This causes an issue when others attempt to work on the code for a certain application or simply download the code and run the app. I have my work spaces for my computer defined, but others do not.
What I want to do is have a way to set up a work space or sort of work space template where anyone can download the code from the server, while on any machine and with the required folder structure, and the application will run.
For instance, if I had the following server structure:
$/
$/SolutionFiles/
$/SubFolder1/
$/SubFolder1/ProjectA/
$/SubFolder1/ProjectB/
$/SubFolder2/
$/SubFolder2/Project1/
$/SubFolder2/Project2/
...and I had a solution $/SolutionFiles/MyAppSolution that contains code from $/SubFolder/ProjectA/ and $/SubFolder2/Project1/, I want to have a separate workspace or something, possibly named "MyAppSolution_Workspace" or something like that, that will map the solution folder and the related project folders to a generic path. This would need to work and be accessible from all other separate computers and would need to keep the same directory structure from the server and have the same folder names and everything as is expected by the solution/project files.
From what it looks like Shared work spaces in VS2010 would work, but it seems to only apply to one machine and is not entirely generic.
Are there any suggestions for how to accomplish this?
You probably won't like this answer but here is what we do:
Keep your workspace mapping as simple as possible. Never move folders or rename folders or files using the workspace mapping. Then all users need to do is map from the top and everything works. They may get more files than they want but it will work.
Advanced users can use the folder cloaking ability to block getting folders they aren't interested in or can map just the folders they want. The key being that when they map specific folders instead of the root they leave the paths the same as they would be if the root was mapped.
In our system we then have our version and release branching structure above the folders of your example. So everything you've listed would be duplicated inside a MAIN folder and inside a Release_1 folder.
I have a solution file that has the following example projects:
SharedLibrary
NonSharedLibrary
WebProject
WebProject.Install
Then another solution file that has the following example projects:
SharedLibrary
WindowsServiceProject
WindowsServiceProject.Install
Currently I open both in two separate instances of VS2010. The share library is the same in both but shared through my source control.
Is there an easy way to create another Solution file that when opened, opens all necessary projects for both. Then when testing, etc. you just change your startup project.
All the while maintaining the ability to open the old solutions if you want to just work on one of them.
Has any one does this before and/or know of a good methodology?
Visual Studio solutions are basically containers that group projects together. You can reuse the same projects in multiple solutions. A common way of handling this is to have one solution that contains all of your projects. Then create additional solutions that only load some of the projects. For example, you might make one solution for UI developers that only loads the projects they need while other developers might not care about the UI but need the windows service.
Each developer can set their own startup project which is stored in their local .suo file.
If you have multiple solutions open simultaneously and you change one project then you'll get the reload message in the other instance since they are shared.
Sure. Just create a new (or several) empty solutions right next to your existing one and then just add to it the projects you want to see there (Add Existing project)
In an earlier question, I've found out that sadly Solution Folders are not real folders inside a directory.
I wonder if there is an AddOn or Macro that adds this functionality? i.e. when I create a Solution Folder, it created a real folder. When I Create a new Item (Right Click => Add => New Item) it automatically moves them into that folder, removing causes it to delete it from disk (after asking) etc.
This is for Visual Studio 2005, although we might upgrade to 2008 in a few months.
As of now, this doesn't seem to be possible in either VS 2005, 2008 and 2010 and there is no AddIn for this.
I too thought it was a strange idea. However it can be a useful tool to logically group projects in solutions without necessarily moving around folders in the file system.
I suspect you need this for revision control tool. In that case Look at AnkhSVN.
Maybe what you want is to add files to a solution folder as «links», i.e., keeping the files where they are but giving them a different organization inside the solution.
(when you add an existing file to a solution folder or to a normal project folder, if it is in a different corresponding physical folder, the file is copied).
It usually stays unnoticed, an option in the «Add > Existing Item ...» dialog where you can choose "Add As Link", instead of the "Add".
This allows to share files amongst projects, or, simply, organize them differently.
What I oftem miss is the possibility to add "virtual" folders inside a project, for organizational purposes, without breaking the namespace/folder best-practice.
Can't really get the point you want to add this function.
Sometimes you want to know if it can do this , however, the answer may be no. But it is not necessary means you can't achieve your original goal, there still a few ways to work around it without this.
Additionally, VS solution suppose to be the shortcut of your project settings and should not been included in any hard-code, the solutions may be various between the PCs and IDE envrionment.
I didn't really use VS2005 much, but have been using VS2008 for the past year.
It has a tick box for creating a solution folder when you create a new solution/project.
If you then use the "Solution Explorer" window you can create and manipulate folders and class files within them. This will actually create new directories that match.
Deletion of files from within the Solution Explorer will also delete the actual files from disk.