I'm building a set of T4 templates that gather their data from an XML file. Is there any way to force Visual Studio to regenerate the templates when the XML file is changed?
Presently, the developers must modify the XML file and then rebuild each template to get the changes. My goal is to hide the T4 templates from the developer altogether so they don't have to do any action other than updating the XML file.
Other information: We're using Visual Studio 2008 Visual Basic projects.
I was looking for a similar capability a few months ago but all I found indicated that you can't invalidate template output automatically when another file is changed. (E.g. There is no way to declare that a template "depends" on another file, Makefile style.)
I wound up actually just writing a custom MSBuild task that deletes all T4 output files, effectively forcing all of the templates to be re-run on every build. This may be overkill for your needs, especially if the templates take a long time to run, but maybe you can hack together something to check template dependencies.
If your goal is to hide them altogether, I make an extension called T4Awesome that lets you do that. Instead of your templates being part of the solution and visible in the solution explorer, my extension hides them in a single folder, then presents them to Visual Studio via custom tool windows. Its supports parameter prompting so you might be able to remove the need of your xml file.
Related
In Visual Studio 2010 through 2013, by default (eg. When I create a new Console Application) new solutions output their compiled executable into Solution name/Project name/bin/Debug/. I want them to be output into Solution name/Debug/, and likewise for all other build configurations like "Release".
I can do this by manually going into properties of each project, going to the Build tab, changing Output path from bin\Debug to ..\Debug. I must repeat this for every project and every build configuration.
After dozens of solutions, I'm a bit sick of doing this tedious task by hand every time. Is there a way to change the default output path?
A solution that works for Visual Studio 2013 is sufficient.
This property is defined in each Visual Studio Project Template
So, for example, the C# Console Application template is located in
\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033\ConsoleApplication\consoleapplication.csproj
The csproj is an XML file that you can edit at your will. The build output directory is define like this (for each configuration):
...
<OutputPath>bin\Debug\</OutputPath>
...
<OutputPath>bin\Release\</OutputPath>
...
If you change this file, it will change all your future new C# Console Application projects. You could also write a utility program that list all csproj in \Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates and update them accordingly.
This is not necessary.
One of the projects in your solution is marked as the Startup project, shown in bold in the Solution Explorer window. An EXE project, like your console mode app. You used Project + Add Reference to add references to other projects in the solution so you can use the class libraries that those projects generate in your console mode app.
Those references will have the Copy Local property set to True.
When you build your project, MSBuild will automatically copy the assemblies from their respective bin\Debug directory into the bin\Debug directory of your console mode app, thanks to that Copy Local setting. And it is smart enough to also look at the dependencies of those class libraries and copy them as well.
So after the build is complete, the bin\Debug directory won't just have your console mode project's EXE file but also all the DLLs it needs to execute properly.
There are a few ways that this can go wrong and MSBuild cannot figure out that such a dependency actually exists. Pretty uncommon, you'd for example have to use Reflection in your code to load assemblies (Assembly.Load() and friends). The workaround for that is to explicitly copy the dependency in a post-build event. You didn't leave enough bread-crumbs in your question to judge whether that's the real problem.
What you ask for is certainly possible, the IDE just doesn't make it easy because it wasn't designed to assume this was necessary at all. You'd have to replace the Build + Output Path setting to, say, ..\Debug instead. You can create your own project template with that setting already preset. Create a new class library project, change the setting and use File + Export Template to create the template. You'll have it available the next time you create a project.
But, really, find out first why the default Copy Local machinery isn't working for you.
Rather than changing a global, protected file, you can create your own .targets file that changes the <OutputPath> however you want and import that into your projects. This could also set other defaults you might want to change and don't want to do for every project. All you'd have to do then in your project files is add something like toward the top (after the root element, of course):
<Import Project="$(SolutionDir)\Common.targets"/>
I have personal Visual Studio projects that I would like to expose to the internet. I'm using BatchPurifier to remove metadata from various files but I doubt it gets whatever Visual Studio does.
You only need to "expose" the solution, project and source code files. These are all plain text files that do not contain metadata and can be reviewed with a simple text editor. They do not contain secrets unless you put them in yourself.
If you have resources as well then it is entirely up to whatever program or device created the file, Visual Studio isn't involved.
Poking around github or codeplex is a good way to find out how other programmers publish their projects.
Open the solution and project files in a text editing program such as notepad and remove any metadata you find unnecessary. I doubt you will find a tool to remove exactly what you want, you'll have to do it manually.
I am working on an big old project. MSBuild is used as the build engine. And I see a lot of .proj, .bat, .sln and .csprj files used in the build process.
I know that .sln file and .csprj can be edit relatively easily with Visual Studio. But is there some easy way to help write and comprehend the .proj and .bat files?
Also, I am lost in the numerous environment variables such as $(SolutionFolder), where can I find the definitions for them?
Many thanks...
The following description is based on how I made use of such files in the open source project, http://code.google.com/p/lextudio/source/browse/#svn%2Ftrunk%2Ftrunk
.sln and .csproj should never be manually edited unless you are asked to. They should be mainly maintained by developers via Visual Studio.
Your focus should be put on the .proj file, where custom targets and properties are set. They are usually manually created and calling MSBuild to build .sln/.csproj in an expected way.
You can edit .proj files inside Visual Studio, as VS knows it is a MSBuild script type.
.bat files are usually wrappers over the core .proj file, so as to let you execute a certain target with expected properties, so it may only contain a call command to MSBuild.exe. I usually use Notepad++ to edit such files, as n++ provides highlighting for .bat files.
Many of the predefined properties are documented by Microsoft, as the link posted by #mortb shows.
.bat files are batch files. They cointains script that are executed by the windows command prompt. Each row contains a statement (like copy, execute program etc) that could be entered at the command prompt. I usually edit bat files in notepad, you may also edit them as text in visual studio. The windows help contains more information about batch files.
.proj is a generic Visual Studio project file
Finding a reference to the variables wasn't too hard:
http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
Hope this helps
Every time I rebuild by DBML, I have to adjust settings for auto generated value etc. for individual fields.
Is there a built-in tool which I could use to automate my changes in the DBML when I build? I'm using Visual Studio 2008.
I've not found anything built-in. I just use a T4 template that reads my database on builds and updates the DBML file with new columns and datatype changes - nothing else. That way, once a table is place on the DBML file, you never need to worry about losing your customizations. It's a pain, but a simple workable solution. Though I'd love to know if someone has a better (and free-as-in-$$$) idea.
Will Visual Studio choke on customized .csproj files?
For example, I wanted to add a Target to update the version number in all AssemblyInfo.cs files. I plan to invoke this from the command line with MSbuild.
As another example, I would like to include the build timestamp into the compile, like so. This would be a pre-compile step (I guess), and unlike the example above, this one would run from within a build inside Visual Studio.
Will VS be ok with this?
As long as the code is a valid MSBuild extension, Visual Studio should be able to handle it. Under the hood the project files are really just MSBuild files and MSBuild does the dirty work of the VS build system. So as long as the file remains a valid MSBuild file it should be just fine.
Yes it does allow customizations. We integrated FxCop with our release-mode builds this way.
It will complain when you first load the project file after it's been edited, saying "it's been tampered with, do you wish to continue loading?" Just hit yes and continue on your merry way. It also lets you check a box to ignore the rest of the projects in the solution for the same warning.