03 Nov 2011 | net |
edit
Just a quick hint for others like me, who spent some minutes searching for the EnsureDatabaseExists method when trying to use RavenDb with Multi-Databases.
EnsureDatabaseExists is an extension method on IDatabaseCommands defined in the Raven.Client.Extensions namespace.
To make it work you need to add a using statement for this namespace.
1 using Raven.Client;
2 using Raven.Client.Extensions;
3
4 using (DocumentStore store = new DocumentStore()
5 {
6 Url = "http://localhost:8080/"
7 })
8 {
9 store.Initialize();
10 store.DatabaseCommands.EnsureDatabaseExists("SomeDatabase");
11 }
31 Aug 2011 | net |
edit
A few weeks ago i've started using Cassette, a very nice asset management tool for .net web applications. It will basically take your assets ( javascript, coffescript, css, images ) and do the right thing with them ( combine, minify etc).
While working with it i had a few issues which I've managed to solve and i would like to share them.
File not found in module.txt
The first problem was related to a .css file for the jquery-ui theme that was present in the ~Content/themes/redmond/jquery-ui.medsentry.css folders. My module.txt looked like this:
themes/redmond/jquery-ui-1.8.16.custom.css
Site.css
# other css files
After compiling cassette locally and using the debug symbols to step trough the code I've noticed that cassette was storing a list of files ( assets ) it found in the Content folder but the path separator was "\" instead of "/". After changing the slashes in the included paths in my module.txt everything works as expected. Now the module.txt looks like this:
themes\redmond\jquery-ui-1.8.16.custom.css
Site.css
# other css files
Using Cassette modules with IIS6
Due to some external constaints i had use IIS6 on a test instance of the application. After the deployment I've noticed that the images in the .css files are not working when using cassette modules to combine the files. This was due to cassette rewriting the paths and using Routes to manage them. In IIS6 you have to do one additional step for this to work. Open IIS Manager, locate your application and open the properties window. On the Virtual Directory tab open the Configuration dialog, located in the Application settings section of the tab. In the Wildcard application maps section click Insert and add "C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" or whatever the path to aspnet_isapi.dll is on your system. Click Ok and Apply and enjoy.
Another way to manage the images in the css files is to embed them as data links. Cassette supports this, BUT Internet Explorer <= 7 does not. Also IE 8 has some size limitations.
Image Optimizer for Visual Studio
Not related to cassette but i'd also like to recommend the Image Optimizer for Visual Studio Extension. Exactly what you would expect from an extension with this name :).
25 May 2011 | net |
edit
I've written a cache provider for NHibernate which uses Membase as a cache engine.
You can find the souce code on github.
Example configuration can be found in the test project.
To use the cache provider add the following lines to the hnibernate configuration:
<property name='cache.provider_class'>Nhibernate.Caches.Membase.MembaseCacheProvider, Nhibernate.Caches.Membase</property>
<property name='cache.use_second_level_cache'>true</property></pre>
If you encounter any problems with it drop me a line.
03 May 2011 | net |
edit
This post is an addition to .NET Serialization Choices post.
I've added to the SerializationTests Project the new serialization implementation in Raven.Json.
The Raven.Json Serializer is an extension to Newtonsoft Json.NET serializer and as expected the results are similar. Also the Pros & Cons are similar:
Optimized DOM for Newtonsoft Json.NET
Pro: JSON Based, human readable, platform independent , fast, passes almost all the tests except the ones where the message has public readonly fields that have dirrerent names from the constructor parameters.
Cons: Without automatic testing, naming a constructor parameter different from the field can cause hard to notice bugs where certain fields are not deserialized. It should however be possible to write a deserializer based on the existing one which throws an exception if there are doubts when deserializing.
08 Apr 2011 | net |
edit
Introduction
Serialization is not a trivial problem in any language. In .NET there are quite some choices available for serializing/deserializing objects. Each available option has it's strengths and weaknesses.
I've started a project on git hub SerializationTests where i'm trying to determine what is supported by which library and draw a few conclusions that should be helpful when designing serializable objects and in general when dealing with serialization.
I've started this project because I've been bitten too many times by issues related to serialization, either trying to send a message with an System.Uri property in NServiceBus, or trying to deserialize an object from Json which had an ID public readonly field named different from the corresponding parameter in the constructor. In the end i'm trying to put together a few tips that i hope will be useful in the to myself and others.
Tested Implementations
The following serialization choices have been included in the SerializationTests project:
Update: Added Raven.Json Serializer - see post
Tested Messages
When designing an object that is meant to be used as a message, event or command there are a few approaches you can take:
- public readonly fields and a constructor with appropriate parameters ( my favorite )
- public properties with private setters and a constructor with appropriate parameters ( if you don't like public fields )
- public fields, no constructor ( only generated default )
- public properties, no constructor ( only generated default )
- interfaces with getters and separate internal implementation (ex for events )
- interfaces with getters and setters ( to help serialization )
I say i prefer the first choice since i find it the one that expresses my intentions the best. I want immutable data transfer objects. Also i have to mention that the first time i've seen this approach was in a video by Greg Young about event sourcing and CQRS architecture. To get the idea an event it's defined like this:
1 public class PersonCreated
2 {
3 public readonly Guid AggregateId;
4 public readonly string Name;
5 public readonly string Street;
6 public readonly string StreetNumber;
7
8 public PersonCreated(Guid id, string name, string street, string streetNumber)
9 {
10 this.AggregateId = id;
11 this.Name = name;
12 this.Street = street;
13 this.StreetNumber = streetNumber;
14 }
15 }
Serializers Conclusions
Disclaimer: I have not used all this serializers in real projects and i'm by no means an expert in any of them. Before adopting one of them do you research and try to see if they have any other drawbacks that might not be acceptable in your projects. If i don't mention Cons for one, it only means that i have not been interested in it so much to research it deeper.
Pro: The BinaryFormatter included in the .NET Framework passes all tests except the DataContractOnly test which is expected since it relies on the presence of the [Serializable] Attribute.
Cons: Very Platform dependent. Assembly version dependent. It's complicated to handle different versions of the same class. Requires the [Serializable] attribute which you might not always be able to add.
Pro: Passes all the tests, XML Based, used in WCF
Cons: Requires attributes on the class ( [DataContract] ) and all members ([DataMember])
One of the most common choices when doing serialization in an AJAX Call where the result is deserialized in JavaScript.
Pro:JSON Based, human readable, platform independent , fast, passes almost all the tests except the ones where the message has public readonly fields that have dirrerent names from the constructor parameters.
Cons: Without automatic testing, naming a constructor parameter different from the field can cause hard to notice bugs where certain fields are not deserialized. It should however be possible to write a deserializer based on the existing one which throws an exception if there are doubts when deserializing.
Integrated in NServiceBus. Has caused me a lot of problems when it was silently ignoring some properties.
Pro: XML Based, integrated with NSB, leaving aside the problems i've had with it has performed quite well in a few projects. Even if i don't personally love it, it's actively maintained by the NSB group and can be reliably used if you know it's limitations.
Cons: You might end up with properties being silently not serialized/deserialized
To quote the authors:
Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats.
Pro: Fast, platform independent, compact, throws exceptions when unable to serialize/deserialive, supports versioning
Cons: Needs custom attributes on the class and members that need to be serialized.
Overall a good choice when size and performance really matter.
Pro: it's said to be the fastest json serializer.
Cons: Fails a lot of tests - you have to make sure you write your objects in ways supported by the serializer
Pro: Xml Based, Passes all the tests except the one without the Serializable attribute
Cons: The outputed xml is big
Pro: widely known?
Cons: I must be doing something wrong since it fails a lot of tests.
Conclusion
My first conclusion is that when approaching an architecture that relies on serialization like EventSourcing and CQRS you should carefully plan the way you write and persist the events in your system.
At the moment my choice is Json.NET with a Gzip filter. The main reason is that it has a minimal impact on how i must write events and is efficient in therms of speed and size yet is still human readable.
I'm hoping after i let this sink in a little i'll come back an update the conclusions.
Also i would be glad if others share their opinions & experiences related to serialization.
