I've been searching on the web for this, and maybe I'm just using the wrong keywords or something? I could use some help.
My problem is simple - we have a bunch of reference.cs files in our solution, which were auto-generated by VS2010 when adding services. These files don't add XML comments by default, so when we build the project, I get 800 or so messages in the build list. This doesn't break anything, but it does make the build take (significantly) longer, and mucks up the output screen.
I "fixed" this by adding the appropriate #pragma statments to the beginning and end of each reference.cs file, but if those ever get regenerated, they will have to be re-added by hand. I'd like to streamline that process and just add them to whatever T4 template VS2010 is using in the first place. The problem is, I don't know where that is, or if VS2010 is using something else to build these files?
Can this be done? Is there a better solution? I don't necessarily want to turn off XML comments for the entire project.
Visual Studio does not use T4 templates to generate the service reference proxy classes (Reference.cs). Instead Visual Studio is most likely using the WsdlImporter and ServiceContractGenerator classes to generate this code.
There is a stackoverflow post on using either a custom wsdl exporter or WCFExtras to add xml comments to the generated code. Both of these assume you have access to the code for the services you are referencing.
Related
Is there anyway within Visual Studio / TFS to identify which project produces which dll?
I'm aware you can look under a particular project's properties and see what the name of the dll is, but in the circumstance where you have loads and loads of projects this doesn't seem very efficient.
I've got the situation where I've got a project that references a dll, which includes a method I want to examine, but I don't know what project produces this dll.
Unfortunately, no. The only way I know is that you may could use a decompile extension. (Strongly not recommend to use) Through the source code after decompile, you can view namespace and judge which project produces the dll. (Under normal circumstances)
And you may also have to face some problems such as:
Legal issues
Need to pay for the extension
Only work for C#/.Net
The source code may be confusion and not standard
This should be a one time activity, you can go ahead and take a look into the project file, in case of C# project the csproj file.
If you do not want to do it opening each file, then i would say write a small tool to read all the project files and look for the name.
BTW, this will be different for different projects, and you need to find out the proper location to look.
I'm trying to create a T4 template that will save our developers from creating a lot of boilerplate code that's necessary in our framework. Let's say the developer creates an interface and marks it with our custom attribute. I would like it so that any interface marked with that custom attribute is enhanced by additional methods, which means my T4 template would have to generate partial classes on the fly. However, I would like it so that this automatic generation happens on the fly and seamlessly, preferably when the internal automatic compilation that's used for intellisense happens. You know how when you create a new class in Visual Studio and you switch to another source file and start using that class you didn't have to save or compile it, Intellisense was able to see the new class you created right away? I'd like the same automatic behavior with the code generated from my T4 template. Any thoughts?
You cannot do what you want to do easily, but here are some options ordered from easiest to most likely what you want (hardest).
Create code
snippets
Create a Visual Studio Item Template
Use Castle DynamicProxy to create the extra bits at run time.
Create a separate project to hold the T4 generated classes as described in my answer here
As a pre-step to your project build (modify .csproj file to do this), you can compile the source code from which you want to generated code and then reflect on that, generate the code and then add it to the project before the real compile step. This is what the MSR Orleans project does. You can read their source code here. This is really cool! :-)
I'm looking for a way to call MSBuild with all possible configurations/platforms defined in the solution file.
I've looked here:
Using MSBuild to Build Multiple Configurations
which requires explicit knowledge of the configurations, as you must enumerate them on the command line,
and here:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/066c9dbf-d191-4b8c-8ee1-b9709b56c500/msbuild-for-visual-studio-2010-build-all-configurations-of-a-vcxproj-file?forum=msbuild
which leads to another page that suggests defining another project file to encapsulate the msbuild calls. Unfortunately, it too requires explicit knowledge of the configurations.
So then, is there any way to obtain through the command line, the list of configurations/platforms availalbe to a given project? (It must be the same list that is modified in Visual Studio. ie: adding/removing a configuration in Visual Studio, saving, exiting, and getting the list, would reflect the changes.)
Parsing the solution file as XML is not an option, as it wouldn't be stable if Microsoft decided to change how it is formatted.
You can't parse a solution as XML it's not a markup file without having MSBuild emitting a meta project first. I recommend you play the odds and be pragmatic, read the .sln as a text file and RegEx it on SolutionConfigurationPlatforms pairs, then build the ItemGroup and batch it. If you are truly utterly paranoid about Microsoft completely reengineering the solution file syntax then look inside Microsoft.Build.Construction and/or .Evaluation, the internal SolutionParser, or Roslyn or even Mono since if the syntax changes then those parsers and loaders would be updated accordingly and in case of Microsoft.Build and Roslyn -- simultaneously.
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.
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!