My TFS folder structure has project files four layers deep as according to the example structure below. I reference a Dll that is located in the ThirdPartyLib folder and the file is automatically referenced as: ..........\SolutionHoldingFolder\DEV_Region\ThirdPartyLib\Referenced.dll. The problem is that each DEV_Region is mapped in TFS so each developer has a different folder name for the layer above the particular region. So this breaks the build in our automated build and on every other developer's machine.
The reference should not need to go up the file structure that much. The minimum amount and the path that does not break the automated and every other developer's build is: ......\ThirdPartyLib\Referenced.dll. This path is safe when promoted to the upper branches.
How can I have Visual Studio reference file paths in the most minimal way by default instead of the way that will break merges and automated builds?
Example structure:
SolutionHoldingFolder
DEV_Region
ThirdPartyLib
SolutionFolder
LayerFolder1
LayerFolder2
ProjectFolder
ProjectFile
I am using VS2013.
Edit the .*proj files directly and remove the extra indirection (notepad or unload then edit the project).
Visual Studio is considering the position of the solution file as the base, so you can also use ancillary solution to avoid some levels.
Related
I have read this post thoroughly: How does Visual Studio's source control integration work with Perforce? and found it very informative. However, I have a specific issue that is blocking my use of Perforce in VS.
For the most part, I have no complaints about the plug-in (I'm still using the P4VSCC plug-in because the new plug-in requires conversion by the entire team which can't happen at this time). Once I understood the idiosyncracies, I've had only one problem working with the plug-in.
Our solutions contains many projects that are built into a single deployment package. As such, each assembly is versioned the same. To accomodate this, and other common aspects, we have defined a common "SharedVersionInfo.cs" file which contains the AssemblyVersion and AssemblyFileVersion attributes typically found in the AssemblyInfo.cs file. This file is stored in an Assets folder beneath the solution folder and added to each project's Properties folder as a linked file. This works great from a version management perspective as we only have to change the version in one place and all assemblies are updated. However, Perforce has a problem with this when a new developer first opens the solution or when a new project is added. The only remedy we have currently is to remove all of the linked files (there are 3 per project in this solution), bind the project to source control, then re-add the linked files.
This isn't such a big deal when we add a new project but the solution contains 80 projects (and counting), so this isn't a viable remedy for a new developer!
My understanding is that the problem has to do with where VS thinks the binding root for each project is. After some research, I was led to find where the MSSCCPRJ.SCC files are for the projects. I found there are numerous SCC files scattered throughout the solution structure. So...
First question: Why are there multiple MSSCCPRJ.SCC files in my solution structure?
We also have several shared/common projects that we use in our solutions. This leads to the following folder structure:
/Source
/CommonTools
/ProjectA
ProjectA.csproj
/ProjectB
ProjectB.csproj
/MySolution
/Assets
SharedVersionInfo.cs
/Project1
Project1.csproj
/Project2
Project2.csproj
:
/ProjectZ
ProjectZ.csproj
MySolution.sln
Where both ProjectA and ProjectB are part of MySolution.sln
Second Question: How can I setup the bindings so the /Source folder is considered the root? This would ensure that all projects included in the solution are under the same binding root. Perforce considers this folder to be the root, how do I get VS and the plug-in to do the same?
Since no one else has offered up a solution, I thought I'd follow-up with my own findings for anyone else that comes across the thread.
First, I still have no idea why Visual Studio creates multiple MSSCCPRJ.SCC files but these are the key to establishing the "binding root" for a solution. It is critical that this file exist at the highest level necessary so that ALL of the projects in the solution are in sub-folders relative to the location of this file. In my example above, the MSSCCPRJ.SCC needed to be located in the /Source folder. Having it in the /MySolution folder caused the original problem when adding projects from /CommonTools into the solution.
That said, resolving the issue was no easy task. I had to manually edit the .sln and all of the .csproj files in Notepad. What I found was that some of the .csproj files had the following elements identifying the source control settings:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
I don't know what SAK stands for, but my understanding is this tells Visual Studio to use the binding information contained in the .sln file.
I had to change these to:
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
where the SccLocalPath value is the relative path from the .csproj file to the MSSCCPRJ.SCC file.
I also had to change the SccLocalPathX and SccProjectFilePathRelativizedFromConnectionX statements for each project in the .sln file. The SccLocalPathX value should be the relative path from the .sln file to the MSSCCPRJ.SCC file - a dot (.) if in the same folder. SccProjectFilePathRelativizedFromConnectionX should be the relative path from the binding root to the .csproj file.
I wish I could say that having that in place, I never had to repeat these steps. Unfortunately, I still have to go in and make corrections every time I added a new project to the solution. Visual Studio still wants to use SAK for the elements in the .csproj file and sometimes the values in the .sln file aren't quite right.
But, at least I know what to look for and what needs to be done to achieve my goals. If anyone else has a better solution or a way to configure VS and/or Perforce so these settings are created correctly up-front, I'll gladly give credit.
Hope that helps...
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
In Visual Studio 2010, how to I set up my VC++ import directories so that I can build my project from multiple machines? For example, my project requires the use of a graphics library that's installed on both of the machines I'm using, but located on different paths.
I imagine the answer is some sort of macro, but I'm new to Visual Studio, so I'm not sure if my intuitions are correct.
I'm transitioning from the Matlab environment, where you can set the path directly per machine, rather than per project. Does Visual Studio have such functionality, or is everything at the level of project properties?
You can indeed use macros to set your include and lib directories on a per machine basis.
if you have your files in your project directory you can use:
$(SolutionDir)\ This will point to the full path of your solution directory root
$(ProjectDir)\ This will point to the full path of your project directory root.
You can place your graphics library in your project directory and point to it like:
$(ProjectDir)\graphicslib, for example, or any other place you want to put it in your solution.
More info is located here http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
use a hierarchy of property sheets, or use a tool like CMake to generate project files for you (as it should automatically find all the libs/includes).
For the property sheets: add the same property sheet to each project. Withing that property sheet, include other property sheets with predefined names. Then on each computer you work, you will have to provide those 'per-machine' propert sheets. For example:
main.vsprops -> include by every project
|- matlab.vsprops -> sets the lib/includes for matlab runtime
|- opengl.vsprops -> sets the lib/include for opengl
Now in your versioning system, you provide a default for matlab.vsprops and opengl.vsprops that contains suitable dfeault values and a batch file to create them. This way you can checkout from the VCS, run a single file, edit the vsprops and start coding without too much hassle. For example:
main.vsprops -> versioned
matlab.vsprops.def -> versioned, contains defaults
opengl.vsprops.def -> versioned, contains defaults
create_vsprops.bat -> versioned, copies *.vsprops.def to *.vsprops
For a long time looking for a way to manage references, I haven't found any ideal way.
The main problems are:
1-) Should I include all projects that I use in same Solution and reference the Project? Or reference just the dll file?
2-) If I should reference dll file, the best way is to create a ReferencedAssemblies inside each project or a main folder at svn root?
3-) Its ok paste and reference dll´s inside bin folder of my project?
4-) Its ok add and commit dll´s inside bin folder of my project? This way when a new devoloper checkout the project, it will compile perfect, but isn´t default behavior of visual studio, all source controls ignore bin and obj by default, just adding .refresh files(for web-site project)
Someone can help me?
1) If you include projects in your solution that are already checked in somewhere else, you can change the SVN binding for that project at the solution level in Visual Studio. (File > Source Control > Change Source Control). You would change it to point to wherever it's located in your SVN repo.
2) If you have a lot of developers on different machines all wanting to use the same libraries, it's probably easier to have a common place for all your third-party libraries/assemblies. There's no point in having them copied all over the place in your SVN repository.
3) No, it's not usually ok to do this. I would avoid it (unless somebody has a valid reason for it).
4) Never commit your bin folders. The default behavior is such for a reason. The .refresh files are byproducts of the old Web Site projects and they are fine.
1) In the typical scenario yes, you should reference all projects that you own. But you should make a decision according to frequency of changes made to referenced projects. For example if you have an open source library it is better to include it as an assembly, cos you probably will not change this code frequently.
2) Typical approach is to create separate single directory at SVN root and place assemblies there in different sub-folders according to assemblies type. Here is how my current folder looks like:
3) No, it is better to reference assemblies from some other from bin folder. All referenced assemblies will be copied to the bin while building process. Also note that the purpose of *.refresh files in the bin folder is to prevent you from having to copy new versions yourself.
4) No, you should never commit your bin folder cos you can rely on *.refresh files for WebSites and just forget about this problem for other project types.
1) I'd argue it depends upon your particular situation, especially since Visual Studio is pretty flexible on what projects are included in solutions. (It's not tied to a directory structure.)
We have a couple applications that have one solution with a number of projects contained within (for each 'piece').
2, 3, 4) For referencing and including files within a project, why not just use the functionality built into Visual Studio? Adding references in this way adds the items to your csproj (vbproj) files.
(Based on my research, if you're not referencing a project that's part of the solution, put the DLLs in a directory everyone on the team can access and use that when adding the reference. In the project file it ends up looking like this:
<Reference Include="Elmah">
<HintPath>\\pathInformation\shared assemblies\ELMAH 1.1 32-bit\Elmah.dll</HintPath>
</Reference>
)
This also means that you don't have to commit DLLs; if anything changes the project file will be updated accordingly.
(I'll admit, I'm unsure about that last point. I've seen a lot of people check in external libraries, like ELMAH. I generally follow those who tell you to ignore the bin directory entirely.)
I am using VSTS 2008. I have two projects (both are written in C#) in one solution file. Project 1 depends on the output (DLL2) of project 2. So, in project 1, I am using "References --> Add Reference --> Browse", then find and select the DLL2 generated by project 2.
My question is, I am not sure whether using such method to add reference will result in some my local computer specific file path dependencies? In more details, suppose both of projects are located in folder d:\testprojectsolution (d:\testprojectsolution\project1 and d:\testprojectsolution\project2), I want to make sure that if I copy the whole solution folder d:\testprojectsolution (with the same structures of project1/project2) to other people under different location (e.g. c:\my documents\sampleprpjects\projects), they could build successfully (not dependent on any specific file path on my local machine, for example, no need to find files under d:\testprojectsolution\project2 or something).
If my approach to add reference dependencies could result in some specific file path dependencies, please let me know how to solve this issue. :-)
thanks in advance,
George
Instead of adding the reference using Browse, add it using Projects tab. It'll automatically consider the project dependency (and thus build order) and other stuff.