Change modified classes generated by T4 - t4

I used T4 to generate some entity classes , but I forgot to make them Serializable. So is there any solution to use something like T4 to add a Serializable attribute to all my classes ?

If you've already modified your generated classes, I think you might find it easier to do with Visual Studio's global replace with a fancy regex to find the classes you need to change. (If that's not possible, it's not hard to write a quick console application to process the files).
Using T4 you can control which files are overwritten, for instance using the Output.PreserveExistingFile which comes with T4 Toolbox.
<#
var t = new SampleTemplate();
t.Output.File = "Sample.cs";
t.Output.PreserveExistingFile = true;
t.Render();
#>
And then you can delete the specific files you want recreated. But however you determine which files to overwrite, any changes to those files that you've made since last regenerating will be lost. One recommendation is to build your templates as partial classes so that you can put all manual modifications in a separate file (but that doesn't really help you if you've already modified your generated classes).

Are those generated classes partial classes? If so, use another T4 template in order to generate a partial class definition decorated with the Serializable Attribute.
Otherwise you could use the Visual Studio CodeModel in order to identify all classes that need this implementation inside another T4 template and then let this T4 template add the code fragments necessary.
If you are using tangible's T4 Editor, it comes with a free Template Gallery and as far as I know there is a template called "Add NotifyPropertyChanged" which does pretty much what you are looking for: discovering code classes inside a Solution and making them implement a given interface. You might adapt that one easily and get your desired functionality.
Hope that helps.

Related

Visual Studio, Nodes in Projectexplorer for Partialclasses

Is it Possible to set Nodes in the Projectexplorer for each Partialclass in Visual Studio?
Example:
Creating a Class-File in Visual Studio with 2 Classes inside, leads to a node for every class.
Creating a Class-File in VS with a Partial class, doesn't result in a new Node for each Partial class.
Is it Possible to have somehting like MurderAllHumans.Constructors and a MurderAllHumans.Methods Node?
I know it is possible to Achieve something simmular with Folders and multiple .cs files, but i am looking for a way to do this in one file.
Thanks in advance
No, this is not possible. The Class view will only show one entry for each class and as two files with a partial class is still only one class, there will only be one entry.
Generally it is advised to have only one class per file, and I am not sure I understand why you want to declare the same class partially twice in the same file either.
Maybe you could solve part of your wish but making one region for constructors and another for the methods etc. like this:
This will however not be reflected in the Class View.

.NET VisualStudio wsdl multiple xsd files, overlapping definitions

I'm writing an implementation for a mailing service and I'm having trouble with the code that VisualStudio autogenerates from the wsdl file. The API contains several versions of the same objects. The objects are defined in separate xsd files corresponding to a particular version:
Although each xsd file defines a specific namespace, the complex element names are the exact same in all xsd files:
This causes VisualStudio to assign arbitrary names to the classes representing the complex names to retain uniqueness:
If you look at the xsd files, OpenMailingGroup_13B returns an OpenMailingGroupResponse and OpenMailingGroup_15A also returns an OpenMailingGroupResponse, and IMHO that's ok from a definition point of view because they are defined in separate xsd files each having its own separate namespace. However, when VisualStudio generates the proxy classes, it names the return type of OpenMailingGroup_13B as OpenMailingGroupResponse2 and the return type of OpenMailingGroup_15A as OpenMailingGroupResponse4.
This becomes an issue when you update the web service reference and new versions are added and removed (e.g. a new OpenMailingGroup_17X now exists). The problem is that VisualStudio would now use a different naming for the OpenMailingGroupResponse. What was OpenMailingGroupResponse4 for OpenMailingGroup_15A could not be OpenMailingGroupResponse9. And that breaks our code.
We thought of a few possible solutions:
Writing adapter classes - but there are literally hundreds of classes and that would be too painful.
Using var in the variable definition in order not to hardcode the type, but there's lots of nesting involved (e.g. a complex type has another complex type which has another complex type, etc.).
Not update the wsdl...
So, my question is: can I tell VisualStudio to split the generated code into multiple .NET namespaces, each corresponding to its xsd file? Maybe a general question is: is there anything I can do about this?
Thanks in advance,
Tiberiu

Entity Framework: Why do the templates no longer generate ".designer.cs" source files

The default type generation in Entity Framework 3.5/4.0 emits each of the types in "Xxxx.designer.cs" source files (where "Xxxx" is the name of the type being generated). This then allowed for the developer to generate his own "Xxxx.cs" source files where further implementation could take place, or attributes could be added to Metadata classes etc.
The more recent T4 templates that have been made available (POCO, Self Tracking etc.), including the default type generation in VS2012, all genrate "Xxxx.cs" themselves without the ".designer" suffix.
I know that it is easy enough to override the behaviour of the T4 templates to emit the ".designer" within the file names, but am I missing something here where we are actually being discouraged to extend these classes through the partial definitions?
In a recent project where I generated Self Tracking Entities, I found that I had to rename the emitted files so that I could extend the definitions with Metadata class attributes as well as overrides of .Equals(object) and .GetHashcode() (otherwise EF could not detect duplicates properly) for example.
Is there something that I have missed where we are now expected to leave the emitted partial classes as they are or is this merely an oversight and are most of you also having to rename source files being emitted?
Code generation strategy has changed in VS2012. Before the code that was generated was using EntityObject based entities and a context class derived from the ObjectContext class. VS2012 by default generates POCO entities and DbContext dervied context. If you still want ObjectContext based context and EntityObject based entities you need to:
Right-click on the designer surface and select properties
Change the "Code Generation Strategy" from "None" to "Default"
Remove .tt files from your solution to avoid having both contexts and duplicate entities.

T4 custom code blocks

With T4 can you have custom code blocks, that should not be overwritten at generation?
Like PreserveExistingFile but for a block of code in the generated file.
I can’t use partial class in my scenario
There's no way to do this. You should either include unmodifiable code blocks in the template itself, or read them from another file.

Visual Studio code generation - how to deal with developers editing class files

So thanks to the Visualization and Modeling Feature Pack , I can build a uml model diagram and generate a bunch of classes.
But what now? Presumably, my developers will add code to those classes. Useful code, valuable code, and as the templates themselves indicate:
// Changes to this file will be lost if the code is regenerated.
So what is the best solution here? Can I make the modeling project reflect changes to the actual classes? Should I generate partial classes? Modify the default templates to read class files and not auto-generate anything that has been modified? Should I tell developers not to edit model files under pain of....well, pain?
Thanks for the tips.
As far as I know, this is really the key reason for partial classes in the first place. The custom code goes in one file, the auto-generated in another.
You could also create classes derived from the generated ones, and put any changes in there. I also agree with above poster that partial classes could be the way to go.
Although the tools generate basic skeleton classes out of the box, that's really just a starting point. You can easily adapt the generator templates to create your own stuff. Different people want to generate different code from the classes - some even generate XML or SQL. And yep, in C#, partial classes are good to generate, so's to keep the hand-written code separate from the generated bits.
It's good to put lots of extension points in the generated code, where you fill in the details by hand code.
Another neat idea is "double derived": from each UML class, generate a base class and a derived class. The derived one has only constructors. The base class has any methods you generate. So your hand code can easily override generated methods where you need that.
There are several options in the tool and recommending what is best is hard without knowing your scenario. Partial classes are great for some, but not all applications. If you want your UML class to generate a partial class, you can set it's C# stereotype's property to "Partial" and it will do so, and custom code can then be added in a partial class that won't be overwritten. If you want to prevent code from being overwritten, you can do this by setting the overwrite property to False on the template binding that corresponds to the package you are working on. This lets you set your extension code to be in a package that is not overwritten, while your model mastered code is overwritten with the latest model changes. Finally, if you want your code to be the master for your model so it always reflects the latest code, then you can reverse engineer your code by using the architecture explorer to select your classes and then dragging them in to a UML diagram. So for a given gesture, either the model is the master or the code is the master. In this version, we did not implement automated merge capabilities between the two.

Resources