views:

54

answers:

2

I'm using T4 templating to generate some .config files in a project I'm working on.

I've set up a pre-build task to look for all .tt files in the solution directory, and then execute the TextTransform command-line tool, so that the code is freshly generated on each build.

However, I'm now having "Access Denied" errors because (for example) when it tries to execute TextTransform on the Web.UAT.tt file, the Web.UAT.Config file is under source-control in TFS, and thus write protected.

Ordinarily I would select the .Config file in Visual Studio, and do the File->Source Control->Exclude From Source Control thing. Unfortunately, this does not appear as an option for any file which shows up as "nested" beneath another file!

i.e. I can exclude web.tt, but not web.config... I can exclude default.aspx but not default.aspx.cs.

Does anyone have any ideas about how I can exclude the lower level nested files from Source Control, but keep the top level ones?

Thanks!

+1  A: 

I'm assuming you're using TFS here.

You're not going to be able to do this perfectly - since Visual Studio will automatically add any new item added to a project to source control. Your best solution is to look at using MSBuild and issuing a checkout for the output file before running the template (but then you'll likely have to check-in again afterwards). Having a quick look there is http://msbuildextensionpack.codeplex.com/ which I've seen mentioned for the purposes of doing this.

Failing that, there is another way.

  • Delete from source-control the output .config file and check in (best to use Source Control Explorer for this).
  • Run the .tt manually from within VS, it'll add the file again - it should now have a plus sign next to it.
  • Again in Source Control explorer, right click on this 'new' file and select 'Undo Pending Changes'. You now have the file on disk, but not in source control.
  • Now the TT can be run, the file is part of the project (and therefore will get published or whatever), but it's not under source control.

The problem with this will be somebody else loading the project for the first time, their Visual Studio will automatically create the output file if they run the .TT - in that case, they would either need to repeat this process (from step 2) or would need to manually create a stub .config file of the correct name (I would suggest before even loading the project) so that the project sees it and doesn't attempt to re-source-control it.

Andras Zoltan
Thanks Andras. I've used a modified version of your second suggestion to get around the problem.
NeilD
A: 

Ok... I've used an adapted version of Andras Zoltan's answer.

Basically, what I ended up doing was as follows:

  1. Click on the .tt file in Visual Studio, and change the "Custom Tool" line in Properties to be blank. This will remove the .config file from the Solution.
  2. Add a new, blank item to the solution, called whatever the output file for the .tt would be (so, Web.UAT.tt -> Web.UAT.config).
  3. Select the newly added file, and exclude it from Source Control as normal (File -> Source Control -> Exclude).

Now, when you build, you ought to see the newly generated files in the Solution, but without any checking in or out.

There are a couple of disadvantages of this method. First, you will have to do this for each .tt file in the project, and make sure that any other developers are doing the same. Second, is that you can now only generate the output files by doing a build!

I think longer term, I'll probably take Andras's advice, and write some sort of MSBuild script to either check out and check back in the output files, or at least to remove the "Read-Only" flag using < Attrib >.

Thanks!

NeilD
Can anyone else see a better way of doing this? How about any traps that I've missed?
NeilD
@NeilD - a cunning solution. However the problem I'd have with this is that there is no longer any explicit connection between the two files other than name; somebody not familiar with TT technology might simply edit the .config file and then wonder why their edits are being undone. Equally, somebody familiar with TT will wonder why the hierarchy is not there (and might assume that the project is broken!).True, my second solution also requires some communication with other members of the team; but once loaded everything looks as normal.I guess if it works, though, then go for it.
Andras Zoltan