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.)
Related
I have seen most of the time how developers in order to work on a solution, right click on solution folder in source control, select "Get Latest" and... have tons of problems: solution's projects reference other projects from other solutions, missing references, etc...
Here is the simulated example of something similar we have at work...
Now, imagine you have to work on TicketsSolution, specifically - fix some bugs, make changes with TicketsSolution's Web project. Usually developers right click on TicketsSolution's folder in TFS/VSS (whatever) and select "Get Latest"... and the above mentioned problems hit them right in the face.
Turns out, TicketsSolution also includes such projects as
Common.Solution1.Project1, which may have a reference to Common.Solution2.Project1
Common.Solution1.Project2
WCFServicesLibrary project, which may have a reference to SQLServerProxy project
also, some external 3rd patry DLLs that have been missing or placed somewhere under ROOT but outside the TicketsSolution folder...
In this scenario when you Get Latest for just TicketsSolution folder all those references will be missing,
so it seems the only reasonable way to Get Latest would be right-clicking on JUST the solution file, such as TicketsSolution.sln and getting latest of that file only. Then, opening that TicketsSolution.sln file in Visual Studio would hopefully :) reconstruct all the tree nodes within and beyond the solution folder required by the solution.
Even in this approach references for external DLL libabries will be missed, because VS knows how to reconstruct the folder-tree, but it doesn't include DLLs referenced outside of TicketsSolution folder.
But 90% of developers get latest of the solution folder and having tons of problems.
So, my question is - in this scenario, whould it be correct to include external projects in TicketsSolution solution, or it would be more reasonable to add "lib" folder under TicketsSolution folder and drop the dlls of all those external dependent projects in it, and then, reference them from the solution's projects, instead of reconstruction the entire folder tree with all the dependent projects from upper levels (that may and probably will have their own dependencies and reference problems) ??
Lib folder makes life simpler but introduces other issues in you build hierarchy.
Plus you have to store your libraries in source control which to some people is a no no.
I use a local NuGet feed.
I think the simplest answer to your question though, is to create a .bat file, write the check out calls for the folder s you need to check out for a solution, store in the solution root folder on TFS.
Get the devs to click the bat file to get latest on all of the files for the solution.
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 could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
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 have a couple of different solutions, in which some projects may depend on output from projects in other solutions. To manage this, I've been copying dll files from the /bin/ folder in each project to a shared library location after build, and then copy/reference them from there to the dependent project.
However, as the library solution gets larger, this tends to become unmaintainable. Too much of my time is being spent traversing solution directories in Windows Explorer looking for /bin/ folders, and trying to figure out which one, or which ones, of the dll files from each one I need.
Is there any way to give Visual Studio a hint that I want all projects in a solution to have the same output directory? For example, a /bin/ folder directly under the solution folder, where all projects put their output.
If possible, I'd like to achieve this without hard-coded post-build events that copy the files, since that will fail if a project output changes file name, or adds another file. I'd rather like to change the location of the actual output directory - the location of $(OutDir), if you will.
I know you said you don't want to use post build events, but your reason as to why not intrigued me. It sounds like you might be hard coding the name of the .dll in your post build event. That can easily be avoided.
xcopy "$(TargetDir)*" "c:\common\" /Y
The * would just cause everything in your bin/Debug/ folder to get copied to your common folder. You could also just copy dlls if you want. Or, if you use $(TargetPath), you'll copy just the 1 dll that is the result of the project, and not any other related dependencies.
UPDATE
The way we do it is each projects entire bin folder is copied to a subfolder. Suppose you have 2 projects, WebUtil and HtmlParser, where WebUtil depends on HtmlParser. For both projects, use xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y. This will create c:\common\WebUtil\ and c:\common\HtmlParser. In WebUtil, add a reference to c:\common\HtmlParser\HtmlParser.dll. There will now be 2 copies of HtmlParser.dll in c:\common.
c:\common\HtmlParser\HtmlParser.dll // the most recent build.
c:\common\WebUtil\HtmlParser // what was the most recent build when WebUtil was built
This has all kinds of advantages. If you change the API of HtmlParser, WebUtil will continue to work, since it will have the older HtmlParser.dll until you try to rebuild WebUtil (at which point you'll get build errors because of the changed API).
Now, if a 3rd project got in the mix that depended on WebUtil, and you're using some part of WebUtil that exposes classes in HtmlParser, then you'll need to add a reference to both projects from your new project. When you add a reference to HtmlParser.dll, use the one in c:\common\WebUtil. You do this because you're only including it as a necessary requirement of WebUtil. Now you'll always have the version of HtmlParser.dll that matches your current version of WebUtil.dll.
I hope that makes sense. It can definitely be a tricky thing to manage. Just wait till you have to start pulling down all your dependencies using svn:externals =P
You can set the output directory in each project properties.
Right click on the project, select Properties
For C#, it is one of the Build property page, under Output, Output directory.
In VB.Net projects, it is on the Compile tab, in the textbox at the top.