Is it possible to have any control over the class names that get generated with the .Net XSD.exe tool?
As far as I'm aware I don't think this is possible, the class names match almost exactly to whats in the schema.
Personally I would change the class names after XSD has generated the code, but to be honest I usually just stick with what XSD generates. Its then easier for someone else reading the code to understand what classes map to what parts of the XML.
Alternatively, if you have control over the schema you could update that?
Basically, no. If you were writing the classes manually, you could have:
[XmlType("bar")]
class Foo {}
however, you can't do this with the xsd-generated classes. Unfortunately, one of the things you can't do with a partial class is rename it. Of course, you could use xsd to generate it, change the .cs file and don't generate it again, but that is not ideal for maintenance.
Any schema with somewhat deep nesting then ends up with utterly useless names.
I don't know of a way to work around the problem, but my tip to at least reduce the negative impact is this: Define a list of aliases for the awfully-named types. This way you can write code that isn't completely unreadable without losing the ability to regenerate.
using AgentAddress = Example.Namespace.DataContract.RootElementNestedElementAgentAddress;
...
It's a pity this list itself has to be copy-pasted to all code files needing it, but I think this at least constitutes an improvement.
Related
On a recent project we need to talk to a XML web service over HTTP. The project will run for a long time and we know that in that time the schema of the XML is likely to change some what although not drastically.
The service has a bunch of XSD files and we intend to generate out classes from these XSD's using xsd2code for Visual Studio.
I have a few thoughts/worries however. The names for the properties in the class are a little curt and I'd like to make them a bit more friendly, so instead of
private string ix_Rep_St { get; }
I'd rather it was something like:
private string BookingStatus
Even better I'd like it to have intellisense which I could add by editing the generated classes however as mentioned we are expecting these to change a little which could mean having to regenerate it all.
I'm after a way to end up with a set of classes that work with the service, yet are easy to code against (ie they use readable syntax) and have intellisense. I'm not sure how best to go about it.
My options seem to be:
Find away to separate out comments from the generated class file?
Generate everytime and put up with it, have some higher level classes interact with these nastily named ones from the service which should keep the mess contained.
Wrap all my classes in new human friendly wrappers with intellisense added in. Store the XSD's in source control and use that to highlight when something has changed then manually add it in
The wrapper sounds appealing if it where not for the amount of files I need to wrap, 30+ by my rough calculations which makes it feel like a bit of a slog.
Any pointers/ideas?
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to name C# source files for generic classes
We are currently re-evaluating how we do generic classes when we inherit from a general class. Currently we will put the following two class definitions in the same file
class Foo
{
// code for class
}
class Foo<T> : foo
{
// code for class
}
My question is a simple one, should we keep them in the same file, or split them into separate files?
So far the pros to keeping them in the same file is that you have all the code there right infront of you. The con is that when both classes get sufficiently large, it could become un-readable.
What I would like is good reasons as to why we should do one or the other. If you recommend separate file, I would also like you to include possible naming conventions, or a strategy to get around the fact that we can have only one file named Foo
This is a matter of opinion, but I'd keep them in the same file rather than try to maintain some naming convention for one or the other.
While I subscribe to one class, one file, I think there is value in having these together. We really treat these as one class, right? Typically, Foo will be abstract, and is just a way of using our generic types… well, more generically -- in places where the type parameters don't matter and can't be known at compile time.
If the classes become too large, it should be a red flag anyway that some responsibilities should be broken out.
Unless classes are utterly trivial, I never put more than one in a single file. It's much easier, IMO, to find exactly the class you seek when you have a predictable, unique file name, with namespaces based on folders, generally.
For naming your files, maybe this:
foo.cs
foo_t.cs
foo_tuv.cs // for a foo class with three generics
I'd recommend keeping the classes in the same file. It makes it easier to locate all Foo classes. Also, with code folding (regions) you can easily view only a single class by collapsing the other.
That said, I wouldn't say either way is wrong. In the end this is one of those things that will take some experience to come up with your personal preference and find what works for you in your particular project. And you may find that what works well for one project doesn't necessarily work for your next project.
Answered here:
I think the common solution to this problem is to name the file like
this:
{ClassName}`{NumberOfGenericParameters}
This would give you this filename:
Bag.cs and Bag`1.cs
This is the way Microsoft handle this issue in frameworks like Asp.net
Mvc.
Keep these classes small and you can keep them in one file. If you can't keep them small, divide them. If you prefer keeping them in separate files, it's okay too. But keep them small anyway. In case of separate file, I would use FooGeneric name but someone here How to name C# source files for generic classes recommends Foo`1 (for 1 parameter).
I have stored my common namespaces used in my Linq to Xml parsing in a config file. Where is the best place to access them in my application? Put them in my base class? Create a Config Class that I can call (call namespaces via accessors), ? What would be deemed a good practice here. I currently have about 7 namespaces.
Thanks,
S
What is the requirement? You currently have the namespaces in a config file which allows you to change them without recompiling the application. If you feel this is useful, I would keep them in the file and, as you suggest, create a type to hold the values at runtime which can be passed as a dependency to any code which needs to know about the namespaces.
If however, you expect these namespaces to fixed for ever, it may be reasonable to hard code them into your base class or wherever else in the source code makes sense (this could also be done using embedded resources rather than string literals).
This latter option would have the benefit of reducing unnecessary noise in your config file and the need for the added dependency type, but I would suggest that, in most cases, it's probably just as well to use the config file pattern regardless. Yes it may be a little extra clutter, but in this business things that you think will never change have a habit of changing.
Also, you say that you currently have 7 namespaces. This suggests to me that you think you may have more or less in the future. For this reason, it sounds like you probably should be using the config file pattern.
I want to build a visual studio plugin that automatically annotates classes for serialization. For example for the built in binary serializer I could just add [Serializable] to the class declaration, for WCF it could add [DataContract] to the class and [DataMember] to the members and properties (I could get [KnownType] information through reflection and annotate where appropriate). If using protocol buffers it could add [ProtoContract], [ProtoMember] and [ProtoInclude] attributes and so on.
I am assuming that the classes we are going to use this on are safe to serialize (so no sockets or nonserializable stuff in there). What I want to know is what is the easier way to take an existent piece of code (or a binary if that's easier) and add those attributes while preserving the rest of the code intact. I am fine with the output being source code or binary.
It comes to mind the idea of a using a C# parser, parse everything find the interesting code elements, annotate them and write back the code. However that seems to be very complex given the relatively small amount of modifications I want to make to the code. Is there an easier way to do so?
Visual Studio already has an API for discovering and emitting code which you might take a look at. It's not exactly a joy to use but could work for this purpose.
While such a plugin would certainly be a useful thing, I would consider rather making an add-in for a tool like ReSharper instead of VS directly. The advantage is somebody already solved the huge pile of problems you haven't even dreamed of yet and so it will be a lot easier to build such a specific functionality.
it looks to me like you need to have a MSBuild task similar to this one http://kindofmagic.codeplex.com/. is that about right?
As discussed in Does the order of fields in C# matter?, the order of serializable properties affects, among other things, XmlSerializer output.
But if fields are in 2 files (using partial classes), does anyone know what in fact controls the resulting order? That is, which file's properties comes first?
(Background: I ask this because I've run into a scenario where one of the 2 files is auto-generated from xsd, and the other is manually edited. The test output is different on developer boxes vs. our scripted build box. Presumably this is a side effect of the several differences in the timing and history of the xsd->C# step in the 2 environments. Various ways to fix, but I'd like to understand the compilation process a little better if possible.)
Nothing is guaranteed per C# spec.
I've found that using the 'easy' approach to making an object by marking it [Serializable] is usually only good enough for very simple implementations.
I would recommend that you implement the IXmlSerializable interface which is pretty easy to do and gives you all the control you need.
Here is what we found out through the fix of a nasty bug:
We had exactly the same problem, our serialization order has changed after a release without modifying any of the serialization related classes.
We had one half of a class generated from xsd-s, and the other half was hand-made. The order attributes were effect-less. What we saw was that before the release, the hand-made partial parts were serialized first, and after it the order changed.
The solution was in the order of the files in project file, that contained the two classes. It turned out, that after an MSBuild (on our build server) build, the serializer will put the elements of the earlier (in the csproj) ".cs" file first in the serialized XML. Changing the order of the ".cs" files in the csproj swapped the order and the generated parts were up front as needed in the XML.
This is is aligned with the answer and observation of Eric Hirst above, as renaming the file reorders the csproj's items (they are generally in alphabetical order). Watch out for editing the csproj by hand for this reason too.