Output Path for Shared T4 Template - visual-studio

How can I specify the output path of a T4 template?
When I add my T4 template using "Add as Link" to my project from $TemplatePath$, it generates the output file in $TemplatePath$, not $ProjectPath$. How can I specify that $ProjectPath is where the generated file is placed?

I got around this by having a master template in one location and then templates that imported that one (but did little else) in each project. Of course, that's not the nicest solution.

We typically use the same system that Jeff Yates mentioned with minimal (often single line) stub templates including the shared template.
You could also use Oleg Sych's T4Toolbox to project output to any directory you please.
However, the standard IVsSingleFileGenerator that T4's custom tool is built upon doesn't have any dials to turn to control it's output location and it's behavior in the case of linked files is as you describe.

Related

Why do vcxproj.filters files exist?

Shouldn't vcxproj.filters be embedded in the .vcxproj? As it stands I have to check this in to source control so others can see the folder structuring in the solution.
According to what Dan Moseley says in this question, they also wanted to separate the tree structure from the build specific information because changing the tree structure would cause an update to be made to the project file, and that in turn would trigger a rebuild. By moving the logical view of the project to a separate file this is avoided.
They were embedded in fact, in previous versions of Visual Studio. The extension was still .vcproj and the filters were stored inside the project file. However, as of 2010 it was decided to pull the .filter information into a separate file.
It is really up to the design teams now to decide whether to add this source control or not. If you want all the developers to have the same structure (for reasons of communication) it might be wise to check them in. If you want to allow each developer to use their own logical view, then don't.
The vcxproj file contains the commands for the msbuild environment. So it contains the files that should be built and the arguments for the compiler how to build/link etc. the source files.
Due to this, the development team decided that the 'view' of the files in the solution explorer should not be contained in the msbuild file, but in another file.
So this was done to separate the build settings from the view you have.

How do I create a Visual Studio project template that includes linked files?

In Visual Studio 2010, I want to create a project template that includes links to two files that should exist on the system. One of them is a common AssemblyInfo.cs file. Another is the strong name key file (*.snk).
I need these references to be relative, because each developer's workspace will be set up differently. Is it possible for the project template to somehow figure out where these files reside in each developer's environment?
From reading about templates, it sound like they're pretty static so I wonder if tricks can be done to do something like this. If nothing else, I can add bogus references that will cause compilation errors and force the developer to hook these files in. But if I can do it for them, that would be better.
You should set the CreateInPlace property to true in the vstemplate. The documentation says
Specifies whether to create the project and perform parameter replacement in the specified location, or perform parameter replacement in a temporary location and then save the project to the specified location.
If you want relative paths to work, you need the parameter replacement to occur in the place where you're creating the project, not in a temporary location.
Microsoft have confirmed that this is a bug with the extensibility model and project templates. I managed to get round this by using IWizard. I added the following code in the RunFinished method of my IWizard implementation:
//Get linked file directory
string coreDir = Path.GetDirectoryName(MyProject.FullName);
//Data folder
ProjectItem propertiesProjectItem = slSharedProject.ProjectItems.Cast<ProjectItem>().Where(p => p.Name == "Data").First();
propertiesProjectItem.ProjectItems.AddFromFile(coreDir + #"\Service\TheFileIWantToLink.cs");
This code links in a copy of TheFileIWantToLink.cs file to my shared Silverlight project (slSharedProject).
You could try to integrate a Wizard into your Project Template and set the Paths to the linked files. If i remember right you don't have to create an User Inteface; you only have to specify the correct replacements in the replacementsDictionary and VS will replace the values in your Template File. See this or this for further information.

Two Custom tool s for a single file?

I want to generate some code from my dbml(Linq to Sql) file,the dbml file is placed in many part of my project So I wrote a custom tool for this purpose
But the problem is that dbml already has contained MSLinqToSQLGenerator custom tool ,
So do you know any way to set two custom tools for one file, If no, Let me know your idea about that
Visual Studio will only support a single "Custom Tool" per file, but you can add a pre-compilation step to run other tools against anything you want. For instance, I have the following pre-compile step set on the "Build Events" tab of one of my projects.
"$(DevEnvDir)..\..\..\Common Files\Microsoft Shared\TextTemplating\10.0\TextTransform" "$(ProjectDir)DataContext\Northwind.proxy.tt"
There's a lot of relative pathing going on here in order to find the T4 command-line tool, but you get the idea. This particular T4 file counts on being in the same directory as the .dbml file that it reads to generate its output.
Before the project is compiled, you can run whatever external tool you want. Just make sure that after the first run, you include the tool's output in the project. After that, since the file gets changed as part of a PRE-compile step, it will always be updated in each build.
You'd get proper control on the T4 if you include the LINQ to SQL T4 generator in your template's responsibility.
If I understood properly, you want to keep the default behavior of .dbml generator, but also add your own.
This seemed a bit "old", and I haven't personally used LINQ to SQL for some time, but I did use this as-is replacement of T4 generator, that produced the equivalent of the standard .dbml generator.
https://github.com/damieng/L2ST4
Not sure if that's up to date with VS 2010 version, but you can always compare the standard .dbml generated code and this T4 output and make proper changes to achieve identical outcome.
Of course you can simply have multiple different generators, and simply run them with "Transform All Templates", but based on your question, you'd want the generator to be attached to the file specific custom tool.
You might want to check out (unless its already familiar to you) also T4 Toolbox https://github.com/olegsych/T4Toolbox that adds "T4ScriptFileGenerator" custom tool to a file. It effectively runs the T4 code when the file changes.

Working with XSLT in Visual Studio

In my C# client application, I use XSLT to transform XML into HTML.
I would like to be able to edit these files in place, without having to recompile the entire solution. I'm having trouble working out how to set up Visual Studio 2008 to allow this.
The problem is that the XSLT files must get copied to the output directory somehow. Currently this happens during the build process. (My XSLT files are set to "copy if newer".) The build process can take a few minutes, which seems excessive for making small tweaks to the HTML.
I could make my XSLT edits in the output directory itself, but the output directory is not under source control. I have accidentally wiped out my quick edits several times by building my solution.
I'd like to reduce the cycle time for debugging XSLT, while keeping my XSLT files under source control and preventing accidental overwrites.
Summary of Responses: It appears that the most practical approach for solving this problem -- given that Visual Studio doesn't have a nice way of doing it out of the box -- is to create a separate project that contains the content files. These files get copied to the output location when the project gets built. That way I don't have to compile the whole solution, just the one project with all the static information like XSLT, CSS, images, etc.
Several folks suggested using sync or batch copy tools, but while this would work for me personally, setting it up for the other members of the team too would be a lot of extra work.
I am not entirely clear about your question, but you can instruct Visual Studio to copy the file from the solution to the output folder every time that you build.
Let me try to understand your scenario:
You have the XSLT files checked into source control along with your C# code. For example, if your project is in a folder called MyProj, then the XSLT files reside in MyProj/Templates
You want to be able to edit the xslt files in the Templates folder and submit those changes to source control just like you do with .cs or other files in your project.
You want a copy of your xslt files in the bin/Debug or bin/Release folder along with your executable.
If that is the case, add the XSLT files to your Visual Studio project. Then right click on them, open Properties, and set "Build Action" = "Content" and "Copy to Output Directory" = "Always". Whenever you build your project, the latest copy of the XSLT files will be placed in your bin/Debug or bin/Release directory.
One approach is to include a C# Preprocessor Directive to point my XSLT load function to the solution directory when in debug mode, but the output directory when doing a release build.
Something like:
string viewFolder = AppDomain.CurrentDomain.BaseDirectory;
#if DEBUG
// Move up from /bin/debug
viewFolder = viewFolder + #"..\..\";
#endif
But that feels like a hack.
Apparently you're managing two concerns in one project. The first concern is your business logic (instantiating an XSLT transform, calling it to transform some XML content, outputting the HTML result....). The second concern is the Transformation itself.
So why not create a separate project for your xslt sheets? "Building" this project would consist of copying the sheets to the output folder. Changing xslt will not influence the other project, hence reduce the build time.
Separation of Concerns at project level, that is :)
You can edit the file directly in the output folder.
On another note, a lot of people don't know that rich tools are built into VS to allow debugging xslts.
http://msdn.microsoft.com/en-us/library/ms255605(VS.80).aspx
One solution that might work for you is to setup a junction to your Templates in your output folder. This would allow you to use the XSLTs directly without copying them to the output folder. A good idea is to ensure (create) the junction as a build action.
Prerequisites:
NTFS
A tool to create junctions (e.g. junction)
Create a batch file that copies your xslt's from their source-controlled location to all your bin directories (bin/debug bin/release or whatever ones you have defined)
Add the batch file as an External Tool, optionally assigning a keystroke (or chord) to execute the batch file
Edit, run tool (I'd assign a keystroke to this to make this easy), then check your webpage.
Could you use a file synchronization program (e.g. Microsoft SyncToy "is a free application that synchronizes files and folders between locations") to copy the files? This would allow you to avoid the "copy on build" step because the files are automatically copied after saved. Also, if you edited them in the output directory, the changes could be copied back into your source controled directory. Not what the best real time sync program is for this scenario is, but that could be another question.
I have exactly the same issue. I have bought a program called ViceVersa (http://www.tgrmn.com/) in which I have setup sync profiles so that my css, layout and xslt folders are synced from my machine to my dev server as soon as any changes are made. If I make any code changes then I just publish as normal.
I understand this is an older post but I found a different solution to basically the same problem.
Visual Studio allows you to 'link' files.
Right click on the folder in the solution where you want the file link to be located.
Click
'Add'
'Existing Item..'
(select the file)
Go the 'Add' Drop down and select 'Add as Link'

Embed the content from an external file when compiling

Is there a way in Visual Studio (any version) to embed the content of a file in another file upon compiling? For instance, if one wanted to embed an xml file in a vb code file how would it best be done?
Add the file to your project, right click on the file and select its properties. Under "Build Action" change it to "Embedded Resource". Now when you compile the file is automatically embedded as a resource.
Here is an example showing how to access an embedded bitmap resource.
Have a look at Resources. You can create a string resource that has your xml. This is then compiled into your application image.
Brian beat me about the embeded resource as I was looking for the resource URL :)
If you don't mind it actually being in your code, you can use an XML Literal.
I was about to mention using the #include preprocessor directive (for C and C++), but then you mentioned VB. I don't think VB supports such a thing.
I have no idea on how to go about doing this. But the first thought that came to my mind was that of Build Providers (the thing that generate classes from xml file in case of an ORM).
I searched & found 1 more thing called Custom Tools, which can act on a file existing in your solution and can be used to generate code file.
See if this link helps at all - http://www.drewnoakes.com/snippets/WritingACustomCodeGeneratorToolForVisualStudio/
What I've done in the past is write a simple .bat file that concatenates 3 different sources into a final source file that actually gets compiled. The .bat file is run as part of the Pre-Build event.
Project
SourceTop.vb
Source.xml
SourceBottom.vb
All of these files have a Build Action of "None"
Merged.vb
merge.bat
type SourceTop.vb > Merged.vb
type Source.xml >> Merged.vb
type SourceBottom.vb >> Merged.vb

Resources