Team Foundation Server Help
I am currently implementing a web soultion using Sitefinity 4.0 RC and I have a general question about Source Control. We are currently using TFS and I was wondering what was the best practices for source controlling a sitefinity solution was (or not source controlling sitefinity project at all because its all generated). I find that we are running into trouble beacuse we have exclusive locking on and developers need to check out the configuration files everytime they need to log in or make an admin change. What is the best solution for this?
Hi Chris,
Thank you for using our services.
You can have the solution in source control. What you need to do (this is what we are doing) is to exclude the configuration file from the project. They will still exist in the folder structure and will be in TFS, however they will not need to be checked out. However your developers should manually check those files (not from solution explorere but from team explorer) when changes are made to the configuration of the website.
Best wishes,
Radoslav Georgiev
the Telerik team
I don't know how you have things setup or if you have some weird settings in TFS (or, if you are somehow taking a different path than me), but following your steps as I understand them will not get you completely to where you need to go.
You have your Sitefinity 4.0 web app project...
You add the entire project to TFS source control (including the config files).
You then EXLCUDE the config files FROM THE PROJECT.
*** This is where I run into problems....
When I EXCLUDE the files from the PROJECT, it wants to DELETE them from source control. Well, I NEED them in source control, because when the next developer comes along to develop, he needs to retrieve the full project INCLUDING the config files.
So, at this point, I have my config files on disk in the right folder structure (NOT included in the project), but NOT in TFS.
So... what to do?
I manually moved the config files into TFS source control.
Great, now they are in TFS. I BELIEVE this is what you were trying to get at CORRECT?? If not, please explain. And, if you were able to take a different route than what I explained, please let us know because with default settings for TFS source control and VS 2010, this is how it happened.
However, we aren't done yet...
Not sure if you forgot to mention or what... but, if you try to run the project at this point you have problems. Specifically, you have issues with the SecuityConfig file and access being denied to it. I'm pretty sure this is because of the READ-ONLY attribute that is now applied to our config files because we have them in TFS.
The only thing I can think of here is to manually go out and remove the READ-ONLY attribute from all those config files on disk. Is that correct?
Is all this the best way to handle a multiple developer scenario with TFS/souce control??
I would love Telerik or anybody else's opinions....
Hello Shawn Krivjansky,
Please look at the following thread, which describes the same scenario:
http://www.sitefinity.com/devnet/forums/sitefinity-4-x/general-discussions/source-code-control-securityconfig-config-and-azure.aspx
Kind regards,
Vlad
the Telerik team
Yes, I'm well aware of the article that you referred to.
If you'll notice, I was the last one to comment in that thread.
My point in the other article was that it wasn't a complete solution (without issues)...and that I would be documenting my process in THIS thread... to see if that is the best we can hope for (because it isn't perfect).
Hello Shawn Krivjansky,
Sorry for missing your post in the linked thread.
You are right - it's not perfect for any scenario. As mentioned in that thread, the Sitefinity configuration and the database are very tightly coupled. This means that some of the configuration settings, persisted for one database, could not be relevant to another. In your development process, you didn't say anything about the database. Is it a shared database or each developer is using own local copy?
Anyway, if you want to put the configuration files in the TFS, I think the best approach is before start working with the project each developer has to check out all configuration files.
As to the problem with the security config, we logged it as a bug with ID: 108673, which will be hopefully fixed for the service pack.
Kind regards,
Vlad
the Telerik team