I currently have a couple of batch scripts in one of my projects which run in a pre-build event which generate some new .cs files by calling svcutil.exe and xsd.exe. I'd like to have these files automatically nested under their base file in the Solution Explorer. I can handle manually needing to include them if necessary, if they'll be automatically nested after they are.
Is there any batch script, tool, or naming convention I can use to make Visual Studio automatically nest them?
Related
Our Visual studio project uses source-base with lot of directories and files.
Other programmers use other ides/systems and when they add new files in the source-base, visual-studio users have to re-add those files into corresponding filter directory (that is 1:1 following directory structure).
Isn't there way to say to visual studio, to follow the directory structure automatically? If that isn't possible, is it at least possible to specify filter contents by wildcards?
I didn't find a way to make it work in visual studio, but the workaround that solved it for us is the usage of fastbuild (http://fastbuild.org). Not only it can be used to speed up the compilation, but it can generate the visual studio files. This allows us to remove the visual studio files from the repository and just generate them on the fly. As the files are specified reasonably in fastbuild ([recursive] directories + file list + exluded files/directories), it automatically works when someone using linux just adds new cpp file into it.
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
After considering folder structure for Unit Testing, we like the default location inside the Project folder. However, we have most of our projects already created w/o the extra folder inside a folder designation. I just did the first project by manually creating a folder, changing the solution file and moving files. Is there an easy way to remap all of these?
You could write a macro that does that - Visual Studio can be automated using VBA, like most of MS Office.
Record the actions to create the new folder, adding to solution etc, then open the recorded macro as a starting point.
Once the macro is ready you can map a button to run it and use that for every project/solution that you need the new structure in.
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.
I have several Visual Studio web application projects that include SVN externals. When a new file is added to an external module, VisualSVN brings it down to the file system, but doesn't add it to the Visual Studio project; it has to be manually added.
I might write a macro to automate this process, and I'm wondering if I can make it a one-step process by either:
Having the macro initiate the VisualSVN update, then do the work (Q: Is it possible to trigger a VisualSVN update from a macro?)
Hooking into a hypothetical "post-update" event from VisualSVN to fire a macro to do the work (Q: Does such an event exist?)
I assume you are currently working like this: your "external modules" are just a loose collection of source files without a project file. Whenever a source file is added, you update all your application project files by adding the new source file, so that it is compiled into all the application assemblies.
I think you are doing it wrong. Your project solution file should contain a reference to a separate visual studio project file for each external. Each source file should be compiled into exactly one assembly.
For example, you might have a C# library shared between multiple web applications. This library has its own .csproj project file, which lives in the external location. If a source file is added to the library, the .csproj is updated. The updated .csproj file is then pulled it via an svn:externals declaration when you update your project.