TFS Suggestions for BTDF Users?

Topics: General Questions
May 27, 2010 at 3:36 PM
Edited May 27, 2010 at 3:39 PM

We just got TFS installed and ready go.  I'm trying to decide on the disk structure. Let's suppose I have two BTDF projects called Common and BookTransfer (in actuality I have 7).
[At this client, we adopted the style of having schemas, orchs, maps in one project called BizTalk.Artifacts].

I'm trying to decide how much nesting we should do on the disk directories (EC is the application name, and Common/BookTransfer or BizTalk Applications separated out for easier deploy/undeploy). 

Proposal #1:

-EC
  - Main
     - Source
        - Common
           - Company.EC.Common.Biztalk.Artifacts [folder]
           - Company.EC.Common.BizTalk.Components [folder]
           - Company.EC.Common.Biztalk.Deployment  [folder]
           - Company.EC.BookTransfer.BizTalk.sln
        - BookTransfer
           - Company.EC.BookTransfer.BizTalk.Artifacts [folder]
           - Company.EC.BookTransfer.BizTalk.Components [folder]
           - Company.EC.BookTransfer.BizTalk.Components.UnitTest [folder]
           - Company.EC.BookTransfer.BizTalk.Deployment [folder]
           - Company.EC.BookTransfer.BizTalk.sln

Proposal #2 - a flatter approach

-EC
  - Main
     - Source
         - Company.EC.Common.BizTalk.sln
         - Company.EC.BookTransfer.BizTalk.sln
         - Company.EC.Common.Biztalk.Artifacts [folder]
         - Company.EC.Common.BizTalk.Components [folder]
         - Company.EC.Common.Biztalk.Deployment [folder]
         - Company.EC.BookTransfer.BizTalk.Artifacts [folder]
         - Company.EC.BookTransfer.BizTalk.Components [folder]
         - Company.EC.BookTransfer.BizTalk.Components.UnitTest  [folder]
         - Company.EC.BookTransfer.BizTalk.Deployment [folder]

 

Current Structure (perhaps too many nested folders)

- Main
   - Source
     - Company
        - EC
          - Common
            - BizTalk
                -Company .EC.Common.Biztalk.Artifacts [folder]
                -Company .EC.Common.BizTalk.Components [folder]
                -Company .EC.Common.Biztalk.Deployment  [folder]
                - Company.EC.BookTransfer.BizTalk.sln
         - BookTransfer
           - BizTalk
              - Company.EC.BookTransfer.BizTalk.Artifacts [folder]
              - Company.EC.BookTransfer.BizTalk.Components [folder]
              - Company.EC.BookTransfer.BizTalk.Components.UnitTest [folder]
              - Company.EC.BookTransfer.BizTalk.Deployment [folder]
              - Company.EC.BookTransfer.BizTalk.sln

Thanks,
Neal Walters

 

Coordinator
May 27, 2010 at 7:33 PM

I'd advocate for your first option, though perhaps skipping the "source" folder.  I'd also skip the "EC" folder - your TFS project most likely accounts for the scoping there.

 

Scott Colestock

May 27, 2010 at 8:17 PM

Thanks.  I didn't include other directories, but most TFS books allow for directories at the same level as source, such as Utils, Install, Database, Docs, etc...

As to the "EC", I'm thinking what would we do when we have a second TFS project?  I know each developer could actually put it anywhere on their disk they want, but I guess I was thinking "EC" would be on the disk, but not itself part of TFS. 

I'm also getting feedback here: http://stackoverflow.com/questions/2922551/tfs-how-much-nesting-on-disk-structure.  The warning someone gave there was against really long directory names might approach the 260 character limit. 

Neal

 

May 27, 2010 at 8:56 PM

What do you do with non-BizTalk stuff?  For example, if I had a WinApp for "Common" above.

Structure #1

-EC
  - Main
     - Source

            - Common
                -Company.EC.Common.Biztalk.Artifacts [folder]
                -Company.EC.Common.BizTalk.Components [folder]

                -Company.EC.Common.Biztalk.Deployment  [folder]
                -Company.EC.Common.WinApp.TestEmail
               - Company.EC.BookTransfer.BizTalk.sln

Structure #2

-EC
  - Main
     - Source
         - BizTalk

            - Common
                -Company.EC.Common.Biztalk.Artifacts [folder]
                -Company.EC.Common.BizTalk.Components [folder]

                -Company.EC.Common.Biztalk.Deployment  [folder]
               - Company. EC.BookTransfer.BizTalk.sln
           - WinApp

                -Company.EC.Common.WinApp.TestEmail

 thanks again

 

Coordinator
Jun 2, 2010 at 4:50 AM

I think your original proposed structure #1 looks good, except if it were me I'd drop all of the redundant names in the folders (Company.EC.Common.Biztalk.Artifacts -> BizTalk.Artifacts).  The parent folder already indicates that this is all part of Common.  That naming structure is not required by the Deployment Framework unless you are trying to avoid explicitly defining in the .btdfproj ItemGroups for Orchestrations, Schemas (which is where your Artifacts project should go), etc.  Most of my projects define the ItemGroups and point to LocationPaths of ..\Orchestrations, etc.  I tend to leave the actual DLL names with the more complete .NET namespace.

Tom

Jun 16, 2010 at 1:10 AM
Edited Jun 16, 2010 at 3:19 PM

One more TFS question.  What about checking in by disk folder vs by solution?  I've tried both ways in two different demo TFS-Projects. As a team, we are trying to finalize our TFS procedures that will handle BizTalk and non-BizTalk entities.  Today, the team consensus was in general that we should check-in by solution.

If I check in by solution, the the only things in the CompanyName.EC.AppName.BizTalk.Deployment directory that get checked in are those items that have specifically been added to the solution - by "Add Existing Items".    I can add all the files that I want by doing "Add Existing" then click on files.  But I don't see a way to include an entire folder.

If I select a folder after "add existing", it just shows all the files in that folder.  If I do CNTL-A and then "Add" it adds everything I highlighted that is a file.  But again, it doesn't catch the subfolders. So unless I do it again, I don't get the 5 files in "EnvironmentSettings" folder.  I assume that checking in the generated MSI is probably not advised. 

If I could do "Add Existing" and select the btdfproj if it was treated as a Visual Studio project, that would probably solve the issue. 

Thanks as always,
Neal

 

 

 

 

Coordinator
Jun 16, 2010 at 6:51 PM

I guess you are using VS 2005 with Team Explorer 2005, which was not the best source control interface.  In Team Explorer 2008 SP1 they completely re-worked the Add Files dialog, so you can point it at a whole directory tree and it can pick out the files in one list.

When I do this myself, I typically add all of the files in <project>.Deployment to the solution and then manually add the EnvironmentSettings folder through Source Control Explorer.  That means just one manual operation in SCE.  Remember that you do not want to add anything from the EnvironmentSettings folder to TFS except SettingsFileGenerator.xml.

Getting the BTDF to exist as a full project in VS sadly looks like too much work to take on.  I've looked at what WiX did since it is open source, and there's a large amount of custom code involved.

Thanks,
Tom

Jun 29, 2010 at 10:58 PM

We went with the original mass load/check-in by "Add Files" (of all our BizTalk projects, folders, and solutions at once). 
I didn't have any problem clicking "Add files" then adding a folder in VS2005.

I just did my first BT Deploy (Local) after being in TFS, and I was reminded of something I had seen more than a year ago at another company.  You have to check-out the following files, otherwise their read-only byte is on:

        Exporting to local_settings.xml...
        Exporting to DEVL_settings.xml...
        Exporting to QA_settings.xml...
        Exporting to PROD_settings.xml...
        ERROR: Access to the path 'c:\SourceEagleConnect\Dev\BizTalk\OSIQueries\FRB.EC.OSIQueries.BizTalk.Deployment\EnvironmentSettings\PROD_settings.xml' is denied.

Since they are re-generated each time, maybe it would be smarter to exclude them from TFS.

Neal

 

 

 

Coordinator
Jun 29, 2010 at 11:05 PM

Correct, you should never add those XML files to source control, only SettingsFileGenerator.xml.

The mass Add Files should work fine although you might have to update your projects to bind them to TFS after the fact.

Thanks,
Tom