We have several teams which share and collaboratively develop a certain SharedProject.csproj, which is a shared component across many products. They do so as each develops its own product (each product has its own solution file).
Each team references SharedProject.csproj in their respective solution file. Neither team has changed anything about that project, but source control keeps reporting the file as changed.
It turns out that each VS2010 solution file references that project, with a solution-specific GUID for that project. Even though the project is the same, each solution references it with a unique GUID.
This solution-specific GUID gets injected into the SharedProject.csproj file each time the next team opens their solution.
How can we prevent VS2010 from changing/editing this SharedProject.csproj file unexpectedly?
Edit each solution file to reference SharedProject.csproj by the same GUID.
Related
Our company is planning to start a large new WinForm project, it will be written in c#-4.0 using Visual Studio 2010.
This project will have many modules (Production, Accounting, Service and etc...) and each module with have lots of possible forms. So we are testing the idea of create multiple projects inside a single solution and have each module be it's own project rather then having a single very large project.
I created a test solution with two projects A and B, next I added each project as a reference to the other project, when adding one project as a reference to the other, I right clicked on Reference>Add Reference>Browsed to the other projects bin/Debug folder and added the other project's .exe as the reference. Next, using the other project as a namespace I was able to do things like form inheritance and opening forms or calling methods between my two test projects.
But I accidently clicked Clean Solution which cleaned the bin/Debug folder for my two projects, and all of my references between the two projects were broken.
What is a proper and reliable way to add permanently references between projects inside a single solution? I was thinking I could physically copy each project's .exe into the other projects bin, then add it as a reference. But that means I'll have to manually re-copy it every time the other project get's updated.
In every tutorial and HowTo site (like here) about WiX I read I should add reference to my other project, but when I select Add Reference I have nothing on Project list in Project tab. I try this on Visual Studio 2012, earlier with WiX 3.7 and now on 3.8.
If there is solution simply not using "Add Reference" function how can I build this other way? I'm a beginner so I don't really know how to use WiX without this feature, if I published my C# application in Publish Wizard I should add all produced files to Component Group with every file in <Component> tag?
It could be this simple...
In Visual Studio, Add Reference's Project tab only lists projects in the same solution. You just need to Add Project to the solution and go back to the Add Reference's dialog.
A solution is just a set of zero or more projects that can be built together. You can have a project in more than one solution. The only limitation is that if project B references project A (B is downstream of A), A should be in every solution that contains B. If the universe of projects is small, it is typical to have only one solution for them all. On the other hand, if one developer works only on upstream projects, that developer might find it easier to work with a solution that doesn't have downstream projects.
Setup projects tend to be downstream but note that they probably don't depend on library test projects.
[Stream is not the best technical term. The universe of connected projects is a directed acyclic graph.]
So I am working on a solution with a lot of projects with multiple developers using SVN. There are some projects that are specific for me that I want loaded but for others they might not be relevant.
So my question is, where does Visual Studio store information about a project begin loaded and what is the proper way to commit project/solution settings with out ruining it for others?
An example could be that I just added a new project to the solution and I want to commit these changes, but I don't want to commit whether or not a project is loaded/reloaded (Since other developers have to reload them again).
EDIT: I found the answer here When I unload projects in visual studio, where does VS save this setting?
When you add projects to a solution, they will get loaded when the solution opens.
If using source control, if such a solution is updated and contains new projects, they will get loaded.
One way of dealing with this is to create multiple solutions - solutions that only have relevant projects. These solutions can be part of source control, but don't have to, though if you don't add them to source control you risk having projects in source control that only you have a solution reference to.
If I have a project called 'testing' in project A.
How can I share that folder 'testing' for project B in visual studio 2010?
The reason I would like to achieve about this is because when I change something in the folder testing of project A, I dont want to change the same things in project B.
Thanks in advance.
Maybe too late for the person who asked the question, but this is for people with similar problems. You can share folder contents with an extention 'Project Linker':
This builds upon the concept of linked files where you refer to the same file from two projects. This extention handles the management of that for an entire project. If you add a file to the project, it will be added too to the other project as a linked file. Same for deletes...
Attention: you need to have both projects in the same solution for this to work of coarse...
Extention VS2015
I used it in VS2010 and it's also availible for later versions.
You can't share folders in Visual Studio - they are logical constructs that are part of a solution or project.
The closest you can get is to add folders to the projects you need to share on and add all the files that you want to share as links. You will still need to manually synchronize all adds/deletes of files, but updates will come across all projects.
To make things easier, you may want to write a Visual Studio macro that synchronizes these folders for you (you can bind these to keyboard shortcuts and/or menu items).
If you put your solution (*.sln) files in the same directory they can share files in sub directories.
We are finally getting a source control system in place at work and I've been in charge of setting it up. I've read that it's usually good practice to not include binaries in source control so I haven't. However, we have two all-purpose utility projects (each in their own solution) that generate utility .dll's which are included in almost all of our other projects (all each in their own separate solutions). We add references to the utility dll from our projects.
I would like to have our solutions set up in such a way that if the reference dll isn't built, the solution will build the dll for itself, much in the same way a make file checks for its dependencies and builds them when they're out of date or missing.
I'm new to build processes with VS so try to keep the answers simple. Any links to general build process overview tutorials would be great too. Googleing for VS references returns a bunch of how-to add references links which is not exactly what I want.
Answer: (3 step process) Add a project reference, not a binary reference by right clicking on the solution, and adding an existing project. Then under the project tab, select project dependencies and modify the project so that one project depends on another. Finally, delete any old reference to the binary and re-add the reference using the project tab in the Add references dialog box.
Where I work we typically have project references rather than binary references (as we used to a while ago). When you include a project reference, the dll will build along with the rest of your app.
The only time we go back to binary references is when we are in between Visual Studio releases (e.g. 1 project is in 2010 and everything else is in 2008. The 2010 project will have to use a binary reference for a couple of months until everyone else catches up... Project incompatibility seems to be a Visual Studio limitation that shouldn't exist).
EDIT
To add a project reference right click the solution and click Add and finally "Existing Project." Make sure that the utility projects are also under source control, and make sure that the workspaces are set up correctly or other people will not be able to open up the projects correctly!