.NET Project Properties stored?

[JTCOO]

Hi,

I'm using Visual Studio 2.0 and Vault 3.5.0 (4741).

When I store a .NET WinForms solution in Vault, if I rename the project folder on my local machine and then do a checkout (as if to recreate the project from scratch using the Vault files), I lose certain settings in the project's Properties file. This behavior is seen when both storing the solution from within VS as well as when adding all files from within the Vault client. Specifically, I would like the XML Documentation File checkbox to remain checked and the file to be indicated. This way, people using this project (a DLL assembly, for instance) will be able to benefit from the extended Intellisense I've put in. Likewise, maintaining any other settings in this Properties file would be highly desirable. What can I do to ensure these are maintained?

Thank you,

JT

[Beth]

Please pardon my ignorance, but is that Visual Studion 2002, 2003, or 2005, or something else?

[JTCOO]

Hi Beth,

Sorry, that's VS .NET 2.0, which is 2005.

Thanks,

JT

[Beth]

When you say you are renaming the project folder, do you mean that you are going straight to the working folder and renaming that, or going into Vault and renaming a folder there, or are you in Visual Studio and renaming something there? I want to go through the same steps you are so I can actually see how this is happening, so any additional details or steps you can provide will help.

[JTCOO]

I create a .NET solution, in this case a WinForms solution. I click on Project... [Project] Properties... and click on the Build tab and enter things like the XML Documentation File, click on the Application tab and the Assembly Information button and change the Assembly Version and File Version settings. I decide I want to add it to source control, so I either add it via the Visual Studio IDE or I open the Vault client and add it that way and set the working folder if it's not already set. Then, to ensure that another person can open the solution and pick up where I left off, I rename my local folder so that if I try to check out the project, Vault does not see an existing project on my machine. Therefore, when it checks out the project, it is creating it by supplying everything necessary to recreate this project in its same condition as it was in the other folder (or theoretically, the other person's PC). And when the solution is built, it should then be identical to the pre-existing solution. However, there are questionable things such as: whether the solution is set to DEBUG or RELEASE, whether or not the solution remembers the XML Documentation File setttings, etc. I haven't created any projects with special Resources or Application Settings or Reference Paths and I haven't verified whether or not the File Version or Assembly Version settings are maintained. I've just noticed a few things that were right in my face.

Thanks for your help.

JT

When you say you are renaming the project folder, do you mean that you are going straight to the working folder and renaming that, or going into Vault and renaming a folder there, or are you in Visual Studio and renaming something there? I want to go through the same steps you are so I can actually see how this is happening, so any additional details or steps you can provide will help.

[gmagana]

When you get the project from Vault (when there is no local copy), do you use "Open From Source Control" within VS2005? I'm asking because I have a project like yours, with XML comments enforced, and it always works for me. Sometimes strange things happen in you get a local copy of a project via the Vault client rather than through VS2005...

[Beth]

I decide I want to add it to source control, so I either add it via the Visual Studio IDE or I open the Vault client and add it that way and set the working folder if it's not already set.

At this point you should add it through the IDE. The IDE has some limitations with source control, so it is best to perform actions one way or another. Either you have it integrated through the IDE and use that for all actions, or you don't integrate it with the IDE and only use Vault.

Then, to ensure that another person can open the solution and pick up where I left off, I rename my local folder so that if I try to check out the project, Vault does not see an existing project on my machine.

You don't need to do that in order for another person to be able to work with files in Vault. They can go into VS and open a project from source control.

However, there are questionable things such as: whether the solution is set to DEBUG or RELEASE, whether or not the solution remembers the XML Documentation File setttings, etc. I haven't created any projects with special Resources or Application Settings or Reference Paths ...

In recreating this, the thing I noticed was that even without any changes, but just opening a project, setting the assembly information, saving the project, making sure it's in source control and everything checked in, and then closing and reopening it, the assembly information box is empty again, so I don't believe that to be information that is always present in that window. All the other settings seem to stay no matter what I do to the folders behind the source control.

In general, you should never need to go behind your IDE or source control. That is defeating the purpose of source control. Working folders are intended for one individual user on their hard drive and are not to be shared, so you do not need to rename yours in order for another programmer to work. They will get the project from source control and create their own. There are some users with alternative methodologies of how they go about their source control, and we can't guarantee any kind of successful results with alternative methods.

A great resource on how to go about source control is found in Eric Sink's weblog: http://www.ericsink.com/scm/source_control.html

We also have extensive KBs on how to work with Vault integrated with VS. Just look in the index under Visual Studio IDE Integration: http://support.sourcegear.com/viewtopic.php?t=792

[JTCOO]

In recreating this, the thing I noticed was that even without any changes, but just opening a project, setting the assembly information, saving the project, making sure it's in source control and everything checked in, and then closing and reopening it, the assembly information box is empty again, so I don't believe that to be information that is always present in that window. All the other settings seem to stay no matter what I do to the folders behind the source control.

I will have to test this again because I feel like the opposite is true. All settings in the project properties that I care about remain set from session to session, including rebooting the machine, yet they don't appear to be maintained in the Vault copies of the files. Maybe these are stored in the registry (I hope not, but I can't seem to find them anywhere else.) Maybe Microsoft can tell me what file needs to be included in order to get the results I want, but they've been unresponsive and I haven't received any information from their forum.

In general, you should never need to go behind your IDE or source control. That is defeating the purpose of source control. Working folders are intended for one individual user on their hard drive and are not to be shared, so you do not need to rename yours in order for another programmer to work. They will get the project from source control and create their own. There are some users with alternative methodologies of how they go about their source control, and we can't guarantee any kind of successful results with alternative methods.

You misunderstood why I was renaming the local folder. This was so that Vault would think I was a new user. Then trying to obtain the project information via "check out" or "get latest version" would theoretically give me everything I needed to work on the project "as if I really was the original user". This proved to be deficient in providing all the necessary data. I don't want to be the recipient of a project that was abandoned by another programmer and not be able to get the full complement of files and data required to accurately recreate the project where he/she left off without scouring his/her local machine. That certainly defeats the purpose of source control.

I was hoping that I could interchangeably use the Vault client and Visual Studio because there are some deficiencies in the Visual Studio interface, but they're not deal-breakers. And, of course, the labeling, sharing, branching, merging, and pinning are probably only handled in the Vault client. However, it was decided by higher-ups to add projects via the IDE; probably for ease of use for others less familiar with source control.

Ive been using source control for many years (VSS). I prefer Vault in virtually every case, but I've never used either for Visual Studio projects so this is new to me concerning what needs to be included in a project.

If you can use your influence to get some answers from Microsoft that would be very much appreciated. Thanks for your continued support in this.

[gmagana]

JTCOO, why wait for Microsoft to answer? Just open your solution and project files in notepad and see which of your options are stored there. Both .sln and .??proj files are stored in source control by VS...

[JTCOO]

JTCOO, why wait for Microsoft to answer? Just open your solution and project files in notepad and see which of your options are stored there. Both .sln and .??proj files are stored in source control by VS...

That would be fantastic, but since I'm storing those in Vault as well, I would think that it would retain the values that I want. But thanks for offering suggestions. Keep them coming. Now one thing I meant to do yesterday but didn't have time to do was open the .??proj.user file and others to see if they contained what I'm looking for. I'll make a point to do that today and let you know the results.

[GregM]

That would be fantastic, but since I'm storing those in Vault as well, I would think that it would retain the values that I want.

Only if Visual Studio is putting those values in those files that are under source control, as opposed to the .user file which isn't under source control.

[JTCOO]

Well, I've compared the files between Vault and Visual Studio and they are identical. The problem appears to be in the process of either opening the solution from source control, or some other adaptation of VS to work with Vault. When I try to open a solution, it does not retain all the settings I need. If I open the solution completely separate from Vault, it works perfectly.

I tried creating a new class library, adding it to source control from VS, deleting the files from my local drive, and then opening it from source control. Some settings were there. Some were not.

Regardless of where the problem lies, it causes me to consider the incorporation of Vault to be unreliable. Thus, while we will continue to use it, I personally am never going to delete any of my projects from my local drive or will always keep a copy on a server drive so that if a project needs to be recreated from Vault, I will have a known good copy to rely on if Vault is insufficient. I'm sure there's a simple solution, but I can't make a career of trying to find it. If you do your own testing and find a solution, I'd be glad to hear it, but for now I'm just going to work with an additional safety net.

[Beth]

Ran another few tests on this. What I found will work is:
1. Close VS before renaming
2. When renaming the folder, you need to make sure you are at the top level folder and not an embedded one. I should mention here that in my case, VS had the working folder set in the VS directory and hadn't changed it to something else.
3. After renaming, reopen VS and perform a brand new open from source control on the project, and set the working directory to something else.

[GregM]

JTCOO, those settings are probably stored in a file that is not being placed under source control. What files are there in your working directory that Visual Studio didn't put in source control?