My solution's files are becoming difficult to easily locate so I though I would create subfolders for some functions. Here is a screen capture of part of my Solution folder as shown in VS2010:
Here's a valid reference to SetupNetwork.NetworkSetup :
showModule(typeof(NetworkSetup));
Here's a reference to SetupNetworkWizard in the same sub-directory:
using (SetupNetwork.SetupNetworkWizard nw = new SetupNetwork.SetupNetworkWizard())
{
nw.ShowDialog();
}
I appreciate there could be two forms with the same name located in different directories however I would have thought VS2010 would have not needed a reference to the sub-directory unless a conflict was found. Whilst one example above is a control and the other is a form, the two calls requirements are contradictory at least.
Is the above 'standard' or am I missing something in my setup of VS2010?
Thanks to Hans Passant who pointed me in the right direction.
I didn't realise that forms created within a subfolder had that folders name appended to the projects namespace.
Related
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
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...
In Visual Studio 2010, I want to create a project template that includes links to two files that should exist on the system. One of them is a common AssemblyInfo.cs file. Another is the strong name key file (*.snk).
I need these references to be relative, because each developer's workspace will be set up differently. Is it possible for the project template to somehow figure out where these files reside in each developer's environment?
From reading about templates, it sound like they're pretty static so I wonder if tricks can be done to do something like this. If nothing else, I can add bogus references that will cause compilation errors and force the developer to hook these files in. But if I can do it for them, that would be better.
You should set the CreateInPlace property to true in the vstemplate. The documentation says
Specifies whether to create the project and perform parameter replacement in the specified location, or perform parameter replacement in a temporary location and then save the project to the specified location.
If you want relative paths to work, you need the parameter replacement to occur in the place where you're creating the project, not in a temporary location.
Microsoft have confirmed that this is a bug with the extensibility model and project templates. I managed to get round this by using IWizard. I added the following code in the RunFinished method of my IWizard implementation:
//Get linked file directory
string coreDir = Path.GetDirectoryName(MyProject.FullName);
//Data folder
ProjectItem propertiesProjectItem = slSharedProject.ProjectItems.Cast<ProjectItem>().Where(p => p.Name == "Data").First();
propertiesProjectItem.ProjectItems.AddFromFile(coreDir + #"\Service\TheFileIWantToLink.cs");
This code links in a copy of TheFileIWantToLink.cs file to my shared Silverlight project (slSharedProject).
You could try to integrate a Wizard into your Project Template and set the Paths to the linked files. If i remember right you don't have to create an User Inteface; you only have to specify the correct replacements in the replacementsDictionary and VS will replace the values in your Template File. See this or this for further information.
I've got a collection of HTML documentation that I'd like to add to my solution in Visual Studio. It's just a collection of files -- there are no build steps.
What's the best way to add this to my solution? In the past I've used a C# class library project and disabled it in Build Configuration, but this felt wrong.
A "Makefile project" doesn't work, because it doesn't support nested folders.
I don't really want to use Solution Folders, because they're not real filesystem folders. This makes them harder to work with. Solution Folders are great when your solution has a large number of projects in it, but I don't think they're great for managing more than a couple of loose files.
How do others do this?
You can put them in solution folder
Right click on solution and select Add->Add existing item - it will create solution folder automatically. You can add solution folder manually via Add->New solution folder
I would recommend simply adding them directly under the solution (or rather under a Documentation folder under the solution). The context menu for the solution title in Solution Explorer gives options to create solution folders and add references to solution files.
Given that you don't want to use solution folders, I see absolutely no point of including them in your solution then. Any method you could use would be rather contrived. It is quite common simply to have a Documentation folder in the root directory of your solution that is not referenced in any way by the solution/project files. (If you like, you can then mirror the directory structure of Documentation using Solution Files.)
I always put a .Documentation folder in each project that I am making the documentation for. It's not as elegant as having a single location for the solution, but it also makes it so that as I use different projects in different solutions and have the documents follow their projects. At compile time I have the build system put all the documentation together in one folder.
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.