Develop Reference

Why would you use 'custom attributes' in your code (.NET)

Could anyone explain the benefits (or reasons) to use custom attributes in your code. Of course I use (and understand the purpose of) defined attributes in certain scenarios (WCF, Serialization etc.), but I cannot imagine any algorithms where I would need to create and use my own custom attributes. Could someone provide a real-world case where usages of custom defined attributes bring something to a project.

The same reason as for WCF etc, but something that's specific to your project - you want to add some metadata to some members (types, fields, methods, whatever) to specify something about the mechanism involved, and it's not something which is covered by existing attributes.
For example, NUnit wanted to add their own indication that a particular type contained unit tests - there was no such existing attribute, so they created TestFixtureAttribute.
It's a relatively rare event, sure - but it can happen.

If you want to write your own system like WCF, Serialization, etc...
If you write code that iterates over types or members and does things with them, you will frequently want to use your own custom attributes to mark some members as being different or special.

I regularly use custom .Net attributes to support tooling in my infrastructure. One example was from very early in the .Net days (C# 1.0 to be exact). I was working on a research project which had a native C++ front and a brand new C# back end written by yours truly.
The front and back end shared a very similar object model which was evolving very rapidly. Not wanting to have to hand code both a C++ front end model, C++ serialization mechanism and a C# serialization mechanism I chose instead to attribute my C# types with custom attributes. They told me the parts of the model which were shared between the front and back end.
Once those attributes were in place I wrote a quick and dirty tool which
Parsed out the attributes to construct the core shared model
Generated the C# serialization code
Generated the C++ code
Generated the C++ serialization code
This made it dirt simple to keep my model up to date between my 2 projects. Just change the C# code, compile and re-run my tool.

I have used annotations in a custom AOP (Aspect-Oriented Programming) system I developed a while back. Attributes are also very useful for controlling orthogonal concerns like code generation.

Custom validation is a very good use case and can be seen from these links:
http://odetocode.com/blogs/scott/archive/2011/02/21/custom-data-annotation-validator-part-i-server-code.aspx
How to create Custom Data Annotation Validators

They can be used for marking tests, as in MBUnit for example. They can also be useful for code that inspects and loads classes (like a Plugin system) to provide meta-information.

They are really useful in building object mappers / ORM tools as well. If you ever decide to roll your own mapping system they are almost "required" to get all the functionality one would need. It's used more for making methods / classes more generic and using reflection to determine how to handle objects / select objects /etc...

To give you a specific case where I've used them. I once had to interact with a Mainframe screenscraper. I created a custom attribute to annotate which fields I wanted to send from my classes to the Mainframe, names that fell outside of conventions, special rules to deal with formatting and collections. I then had a class which was able to reflect over instances and realise which subset of fields were needed to interact with the mainframe screen scraper appropriately.

DefaultParameterValue attribute with XmlSerializer?

We're writing a .NET 3.5 application, which uses Xml serialization of various objects.
We are basically creating an xml document from an object, and i'd like to be able to use this attribute (DefaultParameterValue) which is what .NET 4.0 is using to implement optional arguments.
I'd like the Xml generated document to contain the default values for the parameters that have this attribute.
Is it possible?

XmlSerializer operates at the (public) field/property level. In doing so, one of the things it looks at is the similar [DefaultValue(...)]. It does not look at methods at all, except for a few assistance patterns like ShouldSerialize*(). As such, there would seen to be no crossover at all with parameters, ad no need to look at [DefaultParameterValue(...)].

This is not how attributes work. The ones that xml de/serializers recognize are well documented, the list is not extensible. Adding more requires changing code. Code that you cannot change, it is locked up inside a framework assembly.
Implement the equivalent by assigning the default value you want in the class constructor.

Serializing on Desktop, Deserializing in Silverlight

I'm trying to create content via a small C# desktop app, and have it appear inside a Silverlight application. (I'm creating plain, ordinary C# objects, and trying to make them easily persist.) The context is a game of some sort, where I have a desktop tool that lets me create and edit the content I want, and then the Silverlight binaries consume it.
How can I serialize something in (desktop) C# and deserialize it in Silverlight?
I have a small library I created for serialization; it uses Mike Talbot's amazing serializer for Silverlight, and a simple BinaryFormatter for desktop. Within each platform, these are OK; but across platforms, these two are obviously incompatible.
Is it possible to do this? I would not like to revert back to manually serializing by saving data as text and then parsing it, and I would not like to use an embedded database if possible. I may have lists of lists and other complex data, and manually parsing it is too painful.
If it's not possible, what alternatives do I have?
Edit: ProtoBuf .NET looks OK, but as I mentioned in Marc's comment, I'm using the serializer inside my own library. This means that requiring users of my persistence library to add attribution to classes to serialize them will break encapsulation. I don't want to do that.
What do I mean by breaking encapsulation?
The target user of my library (Persistent Storage) is a game developer. They will use the library to persist information within their games.
Hence, they only consume PersistentStorage.dll. Internally, Persistent Storage uses a serializer (currently, Mike Talbot's for Silverlight, and a simple Binary one for non-Silverlight) to persist data.
For me to say "to use my library, put [ProtoContract] or [Serializable] on all your classes" breaks encapsulation. It means the user knows about the internals of my library usage, which they shouldn't. I can change serializers tomorrow, and they shouldn't care.
I am aware that as a work-around, I can ask them to attribute everything with [PersistMe] and have that as a plain empty attribute that, in turn, extends whatever attribute my serializer needs. But I'm hoping that other serializers, like Mike Talbot's, will not require any attribution to use.

You can try to use Silverlight Serializer
From the author's page:
Serializing Classes Between .NET 4 and Silverlight
You may want to use SilverlightSerializer to share objects between Silverlight and .NET 4, perhaps across a WCF link.
The vital thing to do in these circumstances is to define the classes you want to share in a Silverlight assembly that only references System, System.Core and mscorlib. These are the requirements for assemblies that can be used in both types of project. If you define your classes in this way then they can be deserialized on the back end without a problem, reference anything else and it won’t work. Fortunately most of what you will need is included in those system assemblies!

You need to use the same format in this scenario. Since BinaryFormatter isn't OK for Silverlight, that is out. Personally I'd use protobuf-net, which works on both and can be configured to work on vanilla objects (but is easier if you can add attributes), but if your linked serialiser works on desktop that is a viable option too.
With an example of your model I can be more specific.

Why not try old school xml serialization with the XmlSerializer, both the .Net framework on the desktop and silverlight should have that class. This way there is no addition library to include, its in the framework.

You could also look at Sharp serializer. It allows you to either use xml based formatting or binary formatting for serialization.
I have used it in a similar scenario to share data between a Silverlight and a non Silverlight application and it works beautifully.

Just for reference:
you can build a single SilverlightSerializer DLL and reference it in .net and Silverlight. this works even though the DLL targets Silverlight
Silverlight doesn't run with enough security permissions to enable the inspection of private class members. SilverlightSerializer let's you write support classes to serialize third party components with non-standard requirements, and this can work for private members, but in that particular case it's manual and requires that the serialization class and the serialized class are one in the same.

Have you tried a JSON Serializer like JSON.net ( http://json.codeplex.com/ )?
JSON Specification: http://json.org

We use WCF to do all our serialization to the Silverlight client. We have a dll shared between the client and the server that has all the data transfer objects and interfaces. This allows us to not use the wsdl to generate service ref in silverlight.
To do the searlization we use the DataContractSerializer with a BinaryMessageEncoding. Also you do have to watch out for private setters of objects (which cant be done in silverlight, as you cant set a property with a private setter in the partial trust enviroment of silverlight). If you want to use generics and other things like that, use the NetDataContractSerializer, but that will break compatability with Java and other standards based web services outside of .net (but should work fine for silverlight).
All our DTO's are POCO, other then we add a [ItemKey] Attribute to one of the properties (no other attributes or interfaces), so that our system knows which property is the primary key (this isnt required but it makes things easier to do updates in the persistance layer if things change in the objects).

Untrusted deserialization strategy

I have a pretty complex web of objects I'd like to serialize and deserialize in an untrusted environment (web browser, using Unity 3D). Plain BinaryFormatter serialization is working fine, but deserialization crashes with "access to private field" errors. It works perfectly when I am running locally.
I would rather not make my codebase suck by making all my private fields public. What is the best way to get deserialization to work in an untrusted environment without doing this? I am open to changing serialization methods, BinaryFormatter was just the easiest to get started with.
UPDATE I don't want to prevent serialization from accessing my private data, I want to allow serialization to access my private data without having to make it public, compromising the encapsulation of my code.
Thanks.

Serializers like XmlSerializer and JavaScriptSerializer work against the public members, so they should (crosses fingers) work acceptably in terms of trust. You could also try protobuf-net if you want binary - but I haven't aggressively tested this scenario (it works in things like Silverlight, though, which has a fairly picky trust model).
If you want to stick with BinaryFormatter but don't want it touching your fields directly you could implement ISerializable, but doing it all manually is... painful.

None of the answers really answered my question (see the update for clarification). I ended up writing my own simple serialization format using BinaryWriter. In the end I realized what I did was equivalent to manually implementing the ISerializable interface for my classes. I had to manually implement the graph serializatoin code. While not hard, it's a bit subtle, and it has already been done for me. For future perople with this question, if there are no better answers, I recommend manually implementing ISerialzable.

Well, if you want to prevent the private field access by serialization, you may want to move over to Xml Serialization of perhaps even Json serialization.
You can prevent the private fields from serializing by placing NonSerializaed attributes on them, but you may run into problems when developers expect their fields to contain valid values and do not take into account the fact that those field values get lost when transferred to the Unity plugin.

xsd.exe - schema to class - for use with WCF

I have created a schema as an agreed upon interface between our company and an external company. I am now creating a WCF C# web service to handle the interface.
I ran the XSD utility and it created a C# class. The schema was built in BizTalk, and references other schemas, so all-in-all there are over 15 classes being generated.
I put [DataContract} attribute in front of each of the classes.
Do I have to put the [DataMember] attribute on every single property?
When I generate a test client program, the proxy does not have any code for any of these 15 classes.
We used to use this technique when using .asmx services, but not sure if it will work the same with WCF. If we change the schema, we would want to regenerate the WCF class, and then we would haev to each time redecorate it with all the [DataMember] attributes? Is there an newer tool similar to XSD.exe that will work better with WCF?
Thanks,
Neal Walters
SOLUTION (buried in one of Saunders answer/comments):
Add the XmlSerializerFormat to the Interface definition:
[OperationContract]
[XmlSerializerFormat] // ADD THIS LINE
Transaction SubmitTransaction(Transaction transactionIn);
Two notes:
1) After I did this, I saw a lot more .xsds in the my proxy (Service Reference) test client program, but I didn't see the new classes in my intellisense.
2) For some reason, until I did a build on the project, I didn't get all the classes in the intellisense (not sure why).

Neal, besides all the options John has given you, you should also check out the WCSF.blue tool on Codeplex: http://wscfblue.codeplex.com/
It's a "contract first" approach to doing WCF, and one of the many options it offers is to create a WCF DataContract file from your XSD:
This then pops up a dialog in which you can set a slew of parameters on how to create your C# class file from the XSD:
Quite useful, even if you want to use it for nothing more than converting XSD to C# classes that work as WCF DataContracts :-)
Also see this blog post for more explanations on the XSD DataContract generation process.

Classes that use [DataContract] will serialize to a very limited schema. For instance, there will be no attributes, only elements. This is intentional, and is done for performance and interoperability.
In general, a schema of the kind you may be working with may be much more complicated. Such a schema will not be usable with the Data Contract Serializer. You will need to use the XML Serializer instead.
In particular, don't edit the classes created by XSD.EXE. In fact, you should never edit generated code, as your edits will be removed as soon as the code is generated again. These classes should already have the attributes on them that will be needed for WCF to work with them.
What happens if you just use them as-is?

I'm shocked that no one pointed me to this utility, which I believe is what I was asking for:
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.xsddatacontractimporter.aspx
I haven't tried it yet, but it looks like XsdDataContractImporter was what I was looking for, or the SVCUTIL with the /dataContractOnly flag.
I learned this when interviewing a candidate yesterday. She said DataContract serialization is faster and would be preferred to use.
Neal

Re: your XsdDataContract class mentioned in your followup, IMO, This is a niche class (as is ServiceContractGenerator etc) so i'm not surprised no one pointed you to it.
You still need to package it up to make it really useful. I'm pretty sure that code sample covers only very basic use cases so I would expect to do a lot of work with that to get it to a proper working state. . And like i mentioned on the WSCF forum, Svcutil, wscf, xsd.exe and others all use this class and related classes in the code gen process.
Regards the serializer performance, there are really good posts on Youssef Moussaoui's blog on the different serializers and their performance especially
http://blogs.msdn.com/youssefm/archive/2009/07/10/comparing-the-performance-of-net-serializers.aspx
There’s also a really good discussion here on Connect regarding the two serializers (XS and DCS) and a useful point that XS is still the way forward for WSDL/XSD First development as the DCS is only intended to support a simplified programming model and thus doesn’t support various xml constructs.
http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=451277
Hope this helps,
Cheers,
Benjy