files are removed without asking - .tt.log

Sep 23, 2009 at 12:38 PM

Hello,

We are using T4 to generate files in other projects than the one hosting the TT files. As such a .tt.log is generated. We noticed that if you run twice the template generator, and you do not remove the .tt.log the files listed in tt.log are removed from solution without even asking. If however you remove the tt.log before generating, the files are not removed anymore.

So question is : is this a known bug? Any workarounds? Can I disable generating the .tt.log and tt.txt files?

 

Regards,

Cristi

 

Sep 24, 2009 at 11:46 AM

I added a new issue with this at http://t4toolbox.codeplex.com/WorkItem/View.aspx?WorkItemId=14246

 

Regards,

Cristi

Sep 24, 2009 at 12:46 PM
cristids wrote:

......the files listed in tt.log are removed from solution without even asking. If however you remove the tt.log before generating, the files are not removed anymore....So question is : is this a known bug? Any workarounds? Can I disable generating the .tt.log and tt.txt files?...

 

Cristids --

There is at least one other thread that may shed some light on this matter.

See the following link.

http://t4toolbox.codeplex.com/Thread/View.aspx?ThreadId=64868

From my very limited understanding of the way T4ToolBox works, the log file thta it generates and manages should not be manually touched in any way. It is an internal storage mechanism that is used by the code generation processing. As such, it helps the T4ToolBox with bookkeeping tasks, such as tracking things like what existed before the a given generation action, what exists after, etc. This is not, it seems to me, a bug but rather more like an integral part of the way the T4ToolBox works and it is clearly by design. Given that, changing it would require a code change. The code is available for modifications. Etc.

As an alternate approach, that may help you, please consider hosting the TT Manager-TT-File in the target project where the files should be created. By Manager-TT-File I mean a TT file that contains only project-specific data. That file then can call a generic, reusable Generator-TT-File that exists in a centralized location along with a companion Template-TT-File. That way the Manager is the only thing that is project-specific and it exists where the output exists. The Generator and the Template are reusable. It works great. I have made a full working sample of this and have uploaded in the Patch List section. See the latest version of my sample code, "Northwind01_T4Sample" at the following link.

http://t4toolbox.codeplex.com/SourceControl/PatchList.aspx

HTH.

Thank you.

-- Mark Kamoski 

Sep 24, 2009 at 2:28 PM
Edited Sep 24, 2009 at 2:29 PM

Hello Mark,

 

Thank you for you reply.Well now I am trapped. If until now I was deleting the tt.log as a workaround now I simply have no way out. Your alternate solution is not viable since in our scenario one code generation round generates several files, each in a different project.

 

Regards,

Cristi

Coordinator
Sep 24, 2009 at 2:56 PM

Thanks for posting the link to our previous thread, Mark.

Cristi, I hope you understand our dilemma better. I'm not opposed to implementing this, simply don't have time. Have you looked at using Visual Studio Project Item Templates by any chance?

Oleg

Sep 24, 2009 at 3:22 PM
cristids wrote:

...Thank you for you reply.Well now I am trapped. If until now I was deleting the tt.log as a workaround now I simply have no way out. Your alternate solution is not viable since in our scenario one code generation round generates several files, each in a different project...

Cristids --

Another workaround that may help is to centralize all generated output in a shared custom class library project.

After doing that, one can have all the generated output files in one place and simply add a file-based-reference or a project-based-reference in the consuming projects.

Etc.

Of course, that may not SEEM to work for you.

However, with this suggestion, and with the suggestion above, consider that the suggestion is just a launching-pad for you consider alernate ways of attacking the problem, which often leads to a solution.

That is, "be bold" and "be courageous" with your coding. If it is THAT hard to rearchitect, even for a test, then that may be design-smell, as is the case at my end.

HTH.

Thank you.

-- Mark Kamoski

Sep 24, 2009 at 3:28 PM

All --

I have at least one more thing to say on this topic.

I would like any code-generator to consider that the code-that-generates-code does not have to be perfect, or ideal, or anything close to that-- it just needs to be GEFN.

What IS important is the OUTPUT of the code generation process.

Of course, one does not want a totally klunky and totally hard-to-extend design for the code-that-generates-code-- but it CAN be a little klunky and a little less than perfect.

That is what makes code generation fun.

Code generation is like fingerpainting-- the result of a very messy process can be a work of fine art.

HTH.

Thank you.

-- Mark Kamoski