March 2006 - Posts
So last week
Frans Bouma and me presented the Visual Basic or C# battle. So what was the outcome?
Well in both cases C# took the lead and won. However I am not sad because I lost ;-) In fact I think we showed that in most cases there isn’t a technical advantage to either of the two. There are some exception thought.
When Visual Basic has an edge:
- Office/VSTO development.
The Office object model was created with optional parameters, a feature of VBA, in mind and makes heavy use of it. As Visual Basic supports this it has an advantage over C#, unless of course you like typing Type.Missing :-) - COM interop with older applications.
And in this case I am specifically referring to COM interop without a complete type library, something common in VB6 or Visual FoxPro. This is where Option Explicit Off is a great helper and time saver.
When C# has the edge:
- Very large projects.
In these cases the complete background compilation of the VB IDE and related updating of the Error List window might become a drag. That said I have not worked on a Visual Studio 2005 project where I experienced this. - Unmanaged code.
While there is no speed difference between C# and VB when it comes down to managed code C# leaves the option of unmanaged code open. Unmanaged code makes direct memory manipulation possible, something we showed in a graphics demo where the unmanaged C# version was more than 20 times faster than either the managed C# or VB code.
So what to choose?
- Well keep the product team focus in mind. The C# team focuses in correctness while the VB team is more focused on RAD. So if you want to develop applications faster you should consider VB and if you want more predictable and verifiable results take C# instead. This difference exists today but will increase in the future so choose wisely.
- If you are a manager you might want to consider the average developers background. The C# developer is more likely to have an academic background, something that translates into more theoretical knowledge, higher pay and lower availability.
- Your development focus. C# translates into framework/library building and VB into the glue that puts everything together. Of course you can use either language for either purpose but if you make a choice depending on your activities this is it :-)
- If you want to work with multiple languages that’s ok, although I would recommend not. Just make sure you stick to C# for the library/framework stuff and VB for the application glue. Doing it that way should work fine but doing it the other way round is a big nono in my book.
- Personal preference. And that is the big one and the reason most choices are made. Just be fair and admit its only personal preference and don’t hide behind fake technical arguments :-)
So now you are in a position to make a more informed choice. So choose, code and enjoy .Net :-)
BTW if you are looking for the PPT and samples you can download them from
here.
Yesterday evening I installed Vista for the first time. I guess I am both pleasantly surprised and not so :-)
Good
- While the installation took its time there was relatively little user interaction and all of it in the beginning. All I had to do was leave my old notebook alone and come back an hour later.
- Even though my old notebook is over 2 years old, closer to 2.5 actually, the speed isn’t that bad. Sure it is slower than XP but I guess that is to be expected. Now if I could only remember why that is supposed to be the case :-)
- Security seems to be better. Several times I received a notification that a driver needs to be installed and would I grant it the required privileges. Now I am not a security expert so I can't comment on how secure it is but I am sure someone else will.
Bad
- First I tell the installer that I want to use the Dutch language settings. Next when we come to the clock part it suggest using US time. Now how likely is it that I am living in the US and want Dutch language settings? Not very is my take. So how about a slightly more intelligent default?
- I tried to run Charles Petzold samples from http://www.charlespetzold.com/wpf/ and they wouldn't run because the WinFX runtime wasn't present. Seems kind of strange that the WinFX runtime isn’t part of Vista when that is supposed to be the way to develop .Net applications. Than again maybe there was an older version or MS can’t include it by default because of the lawsuits.
But what I am wondering about most of the time is why people need to upgrade from XP to Vista. Sure it is more secure but most people don't care all that much, large numbers still connect to the internet without a router or decent firewall! Large companies do care but they typically tend to keep their PC longer so my take is that their average machine is going to be to slow to run Vista. Specially when you consider that most business PC's have only mediocre graphics cards and Vista want's a fast graphics card with hardware acceleration.
So I guess that leaves techno nerds, who are going to upgrade to any new gadget, and new PC's sold with Vista preinstalled. Sure sounds like Vista adoption is going to take a while :-(
In a recent
blog post Anko raises the question if functional exceptions exist or if business rule validations should be handled differently. He states that he strongly believe that functional exceptions should not exist.
I have to say that I disagree with him. I do believe there is a case for both technical and functional exceptions. That doesn’t mean that exceptions are the only error notification strategy though.
Take for example a daybook entry in an accounting system. This consists of two general ledger accounts and the amount to be charged to each account. If the data entry form is designed so that the user can only pick two existing general ledger accounts they should never cause a business rules violation right? Wrong, because another user might delete one of the accounts before the daybook entry was written. Now the business rules could first check if the general ledger accounts exist but as the user can only pick valid ones this is not going to fail very often. Even if this check was done it there is always a moment between the check and the actual update. Sure you can prevent the account from being deleted by either locking the data, god forbid, of by wrapping everything in a single transaction. While this would work it would also mean that the connection to the database is kept open longer and the transaction lasts longer, both bad for scalability.
So what was the definition for an exception? According to Anko “An exception is the fact that something happens during the execution of the program you do not expect.” something I completely agree with. So can we consider the case where one user deletes a general ledger account at the same time as another user first uses it an unexpected event. You can argue this either way and both would have a point :-) However this is not going to happen very often. In fact it is very unlikely to happen at all during the lifetime of the application. Now writing the code inside a transaction that is automatically reverted in the case of an exception is easy and takes very little, if any, code. Writing the checks and reverting the updates manually takes quite a bit more code and most, if not all, of the exception code is never going to execute. I don’t like writing code that is never going to execute, seems like a waste of time :-(
That leaves another point, the execution speed.
It is completely true that exceptions are slow, even every slow, as compared to checking for and returning a boolean or enum indicating the failure. For that reason I would never use exceptions as the only means to indicate failure in a tight loop. However the scenario described above is the result of a user saving a single daybook entry, hardly a tight loop in my book :-) Suppose the same business code can be executed from another business process that might be in a loop. In that case I would add a validate function to check, without exceptions, of an entry is valid. This code can be independent of the first update code, manage it’s own connections etc. The tight loop could use this extra function to validate bookings before actually committing them, greatly decreasing the likelihood of an exception.
So what is my recommendation?
- Write the code using exceptions as this produces more reliable and readable code.
- Add optional validation functions that validate the business data without throwing exceptions.
Microsoft recently announced the Visual Basic 2005 “Experience the difference” Tour. One of the stops in this tour would be in Amsterdam. Regrettably this meeting is canceled. I consider this quite unfortunate as we don’t often get VB developer from Redmond in the Netherlands. I can only hope we soon get another chance to hear from them. Fortunately the ASP.NET tour is still on so we are not left completely in the dark ;-)
This is intentionally in Dutch as it is target at Dutch developers.
Microsoft organiseert dit voorjaar een aantal trainingen om ontwikkelaars voor moet bereiden op de komst van Vista. Deze trainingen zijn niet duur, € 50,- of zelf gratis voor partners, dus dat kan geen belemmering vormen.
Windows Presentation Foundation, voorheen bekend onder de codenaam Avalon, is het geünificeerde presentatiesubsysteem van Microsoft voor Windows. Het bestaat uit een weergave-engine en een managed-code framework. Windows Presentation Foundation unificeert de manier waarop Windows-documenten, media en de gebruikersinterface creëert, weergeeft en manipuleert.
Dit stelt ontwikkelaars en ontwerpers in staat om visueel zeer aantrekkelijke, aangepaste gebruikerservaringen te creëren die de band van de gebruiker met de toepassing verstevigen. WPF is beschikbaar in Windows XP, Windows Server 2003 en alle toekomstige versies van het DataBinding-besturingssysteem.
Deze sessie is een kennismaking met Windows Presentation Foundation. De architectuur en de toepassing van WPF worden besproken en gedemonstreerd. In detail wordt ingegaan op DataBinding en XAML. XAML is een taal met opmaakcodes waarmee de gebruikersinterfaces declaratief kunnen worden beschreven voor Windows-toepassingen. Hiermee krijgt een ontwikkelaar nog betere en preciezere gereedschappen in handen voor het samenstellen en ombouwen van gebruikersinterfaces voor eigen doeleinden.
Voor webontwikkelaars biedt XAML een vertrouwd model voor de beschrijving van gebruikersinterfaces. XAML biedt ook de mogelijkheid om het ontwerp van de gebruikersinterface te scheiden van de onderliggende code, wat ontwikkelaars en ontwerpers in staat stelt om nauwer samen te werken.
Datum: 18 april 2006
Tijd: 09:00 - 16:30 uur
This afternoon
Frans Bouma and myself will be presenting a repeat of the session we did last night on the question on everyone's mind: should I use VB or C# when developing a .NET application. Frans is a C# MVP and will take care of that side of the table while I as an VB MVP will try to convince him that VB is the better tool :-)
If you are a member of the SDN usergroup this meeting is free so quickly go to the
SDN web site and register.
This evening
Frans Bouma and myself will be presenting a session on the question on everyone's mind: should I use VB or C# when developing a .NET application. Frans is a C# MVP and will take care of that side of the table while I as an VB MVP will try to convince him that VB is the better tool :-) You can still join us tonight if you register for this free event at the
DotNed site.
This is intentionally in Dutch as it is target at Dutch developers.
Microsoft organiseert dit voorjaar een aantal trainingen om ontwikkelaars voor moet bereiden op de komst van Vista. Deze trainingen zijn niet duur, € 50,- of zelf gratis voor partners, dus dat kan geen belemmering vormen.
Windows Communication Foundation, voorheen bekend onder de codenaam Indigo, is de nieuwste webservicetechnologie van Microsoft. Het breidt de functionaliteit van het .NET Framework 2.0 en Visual Studio 2005 uit, maar kan ook worden gebruikt in combinatie met BizTalk Server 2004 en 2006.
Door dit alles worden Visual Studio-ontwikkelaars in staat gesteld verbonden systemen te maken met de programmeertalen die zij al kennen. Dit resulteert in:
- minder complexiteit voor ontwikkelaars
- minder onderdelen die moeten worden beheerd door IT-professionals
- minder training voor ontwikkelaars en IT-professionals
- een aanzienlijke kostenbesparing voor de organisatie
Deze sessie is een kennismaking met Windows Communication Foundation. De architectuur en de toepassing van WCF worden besproken en gedemonstreerd. In detail wordt ingegaan op het programmeermodel van gedistribueerde applicaties en de keuzes die daarmee samenhangen.
Datum: 21 april 2006
Tijd: 09:00 - 16:30 uur
Next Friday, march 24th we are hosting another
Software Developer Event in Ede. There are a number of interesting session to go to, and don’t forget to come to Frans and my session about Visual Basic versus C#.
If you are a member of the
SDN the meeting is free. If you aren't a member yet this is a great opportunity to do so :-)
Its been a while with the long and miserable winter but finally I got some air time again :-) The weather was actually surprisingly nice with a lot of sunshine. Now if spring just got around to a real start I can get a lot more airtime. And I am still waiting for my new wing, should be done any day now.
If you subscribe to the Dutch version of the .Net magazine you are in luck :-) In it is an article I wrote about the new language features in Visual Basic 9 and LINQ.
Enjoy the article.
Web services are cool and really neat but they do suffer from one drawback and that is that the need Internet Information Server (IIS) as a host application.
Ok maybe it isn't that much of a drawback but would like to be able to host one without running IIS at least some of the time. Well the good news is that it isn't all that hard of you first install WSE 3.0. One of the features of WSE 3 is the ability to host web services in a service (or a console or similar application for that matter). The only requirement at runtime is that the WSE 3.0 runtime is installed on both the client and server machines.
To create a simple server:
- First create a normal web service.
This service is only used for development. - Next create a console application
- Add references to:
- Microsoft.Web.Services3
- System.Web.Services
- Copy the Service.vb from the web service to the console application
- Add the following line to the HelloWorld function:
Console.WriteLine("Request received") - Add the following code to the sub main:
Dim Address As New Uri("soap.tcp://localhost/Service")
Dim endPoint As New EndpointReference(Address)
SoapReceivers.Add(endPoint, GetType(Service))
Console.ReadKey()
Next we need to create a client application.
- Create a second console application.
Add references to:
Microsoft.Web.Services3
System.Web.Services
- Add a reference to the real web service created while developing the service.
- Add the following code to the sub main:
Dim ws As New localhost.ServiceWse
ws.Url = "soap.tcp://localhost/Service"
Console.WriteLine("Press escape to stop.")
While Console.ReadKey(True).Key <> ConsoleKey.Escape
Console.WriteLine(ws.HelloWorld())
End While
Console.ReadKey()
- Run the server.
- Run the client.
Note that we create an object of type localhost.ServiceWse not localhost.Service. This is because adding the WSE reference added some logic to the proxy generation process resulting in two proxy objects. Using the wrong proxy object results in a "The URI prefix is not recognized." NotSupportedException. In that case just change the proxy to the Wse variant. If you don’t have the localhost.ServiceWse proxy class you probably didn’t add the Microsoft.Web.Services3 reference before adding the web service. In that case just add the Microsoft.Web.Services3, right click on the localhost icon below the Web References node in de the Project Explorer and select Update Web Reference to regenerate the proxy object.
Good luck in exploring WSE 3.0
Next week Frans Bouma and myself will be presenting a session on the question on everyone's mind: should I use VB or C# when developing a .NET application.
Frans is a C# MVP and will take care of that side of the table while I as an VB MVP will try to convince him that VB is the better tool :-)
We are actually going to do the same session twice next week. The first time is Thursday march 23 with the dotNed usersgroup, see
http://www.dotned.nl/ for more details. The second time is Friday march the 24th at the SDN meeting in Ede, see
http://www.sdn.nl/ for more details on that meeting.
Both sessions should be a lot of fun so I hope to see you there.
In the two previous blog posts (one, two) I described the general SOA architecture and the kinds of messages we need to send around. Having messages is nice but we still need to define the message format. Part of this message format is a way for the central routing service to get request/response type messages around the system. So lets take a closer look at the messages.
The two most important considerations in message design are:
- Make messages chunky instead of chatty.
- Make messages state unaware.
Making messages chatty means that we send larger complete messages instead of small subsets. In general it is better to send a larger message and have all clients ignore part of it that send only the required subset and discover, at a later date, that part of the available information is missing from a message. So if a users enters a new invoice we are going to send a single message with the complete invoice details that we want the service to make public. Even if we are not going to use all the data in other parts of the application we should still send it. Remember that in a SOA application each service should be, as much as possible anyway, unaware of what others exist and what each does. Now suppose we know that there is no warehousing service only a financial service, this means we could decide not to send the articles sold only the customer and the total invoice amount. If the customer decides to implement a warehouse service at a later date the required information isn’t broadcast. Now we need to either add a new message or enhance the existing one. If we had decided to send the whole invoice in the first place we where already done at the invoicing end, all we had to do is add an endpoint for the invoice message.
Another thing is that we want to make them state unaware. This means we are not going to send a “new invoice” message but we are just going to send and invoice. This means that the receiving end needs to check, using primary keys etc, if the data is new or updated. The benefit is that it doesn’t matter if a message is received twice, something that may happen with a number of transmission protocols. In some cases this does put an extra burden on the receiving side as old state might need to be retained. Suppose the inventory receives a new order with a single article. As the order is new we can just mark a single item of the article as ordered. If the same order is received twice we can do one of two things:
- Realize that the same message has been received and processed and ignore it. Something that is easy to do if each message has a unique identifier, something I really think it should.
- Undo the previously reserved article and reserve it again.
The first of the two options is very easy to implement but also very limited. In most applications data that has been entered can be updated again so the scenario where the existing order is modified and a second article is added is quite common. Handling this case actually exactly the same as processing the same message twice and means that we first undo the previously reserved article and then reserve the two articles.
Of course the 1st option has some benefits two. As we are sure a single message is never processed twice we can send a diffgram style of message with both the old and the new value. Please note that diffgrams are useless if we can process the same message multiple times because the old value in the diffgram will not correspond to the last value used resulting in a wrong total.
So how does is message actually formed? Well a message is basically divided into two parts hold together by an envelop element. The first part of each message is a message header and is basically the same for each type of message. This message header contains information about the message itself. This includes information like:
- Originating service.
- Unique message identifier.
- Security information like a sender identifier or a way to make sure the message hasn’t been tampered with.
The second part is the message body. This is different for each message and is the actual payload that is processed in the receiving service.
The W3C consortium has published a standard format for these kind of messages; the WS-Addressing standard. See http://www.w3.org/2002/ws/addr/ for more details about this standard. Below is an example message taken from the WS-Addressing standard:
<?xmlversion="1.0"encoding="utf-8" ?>
<S:Envelopexmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<S:Header>
<wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.com/business/client1</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
<wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
</S:Header>
<S:Body>
<!-- The actual message payload. -->
</S:Body>
</S:Envelope>
If you decide not to use the actual W3C standard I would recommend using something similar with at least the basic Envelop/Header/Body approach as this works very well.
A request/response message exchange is simply a combination of two messages. Take a look at the following example, again taken from the WS-Addressing standard guidelines.
The request message:
<?xmlversion="1.0"encoding="utf-8" ?>
<S:Envelopexmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<S:Header>
<wsa:MessageID>http://example.com/someuniquestring</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.com/business/client1</wsa:Address>
</wsa:ReplyTo>
<wsa:To>mailto:fabrikam@example.com</wsa:To>
<wsa:Action>http://example.com/fabrikam/mail/Delete</wsa:Action>
</S:Header>
<S:Body>
<f:Deletexmlns:f="http://example.com/fabrikam">
<maxCount>42</maxCount>
</f:Delete>
</S:Body>
</S:Envelope>
The associated response message:
<?xmlversion="1.0"encoding="utf-8" ?>
<S:Envelope
xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<S:Header>
<wsa:MessageID>http://example.com/someotheruniquestring</wsa:MessageID>
<wsa:RelatesTo>http://example.com/someuniquestring</wsa:RelatesTo>
<wsa:To>http://example.com/business/client1</wsa:To>
<wsa:Action>http://example.com/fabrikam/mail/DeleteAck</wsa:Action>
</S:Header>
<S:Body>
<f:DeleteAckxmlns:f="http://example.com/fabrikam"/>
</S:Body>
</S:Envelope>
Using the general guidelines mentioned above and in the two previous blog posts you should be able to get good start with developing your first scalable SOA application. Good luck and let me know if you have any questions.
Last week at the Dutch DevDays I had a change to play around with a
Segway. Though I have known, about and been interested in, the Segway I never had the change to ride one, guess there aren't that many around in Europe :-(
I always figured that it would take quite a bit of practice, it being a balance machine and all, but was pleasantly surprised in how fast I could ride around. Just 20 seconds of practice was about all I needed and off I went :-) Great fun but unfortunately they aren't all that practical and quite expensive to buy so I guess that is all the fun I am going to have with it.
O well you can’t have everything I suppose, although that never stopped me from wanting to :-)
On April 5th the VB Experience the Difference Tour will be in the Amsterdam, the Netherlands with a day of training. If you have the time this is a great opportunity to learn about the new VB 2005 features from some of the people that actually develop VB themselves.
Recommended and I will be there to on behalf of the
SDN.
If you can't make it on the 5th there is another similar event on the 20th of April. This second event is focused on ASP.Net development.
In a previous
blog post I described the general SOA architecture. I finished after describing the two basic message types we needed to send around the system. These where:
- Fire and forget notification messages to multiple endpoints.
- Request and response messages to a single end point.
Now that we know about the kind messages we need to take a look at how to get those around the system.
In the case of fire and forget messages we have a number of choices:
- Send to message to a message pool where every service of the application receives every message. This is very simple to implement using a drop directory, database table or some similar system. However this approach lacks in scalability because each endpoint has to open every message, check the message type and decide what if anything to do with it. When the system gets larger in size with more services and is used more and more the number of messages increase and every service gets busier and busier opening messages that it probably has no interest in at all.
- Create a message loop/pipe line. This approach is also relatively simple to implement and is similar to a token ring network. Each service just has to be aware of one inbound and one outbound queue, read all messages from the inbound queue, optionally do something with it and then send it to the outbound queue. Again the downside is that every service has to open and look at the message limiting its scalability. One additional downside is that if a single service is down all messages stop there and the other services further down the pipeline won’t receive any events until the stopped service is running again.
- A central routing application. I think this is the best way to go. In this case each service sends its messages to the routing application. Next the routing application looks at the message type and compares that to a list of interested endpoints and forwards it to those services. Now this is typically something that BizTalk does very well, not really a surprise as that is what BizTalk was designed to do. Besides just forwarding messages BizTalk has additional capabilities in transforming the message itself, something that is really handy if one of the existing services is replaced by another one. A scenario where it is likely that the new service is designed around a different message format.
We also need to route the Request/Response type of messages. In this case we are talking about an endpoint to single endpoint message. Again we want to make sure that services are unaware of each other. Basically we have the same options as above but in this case we also need to route the response back to the sender. Again the central routing application is the most appropriate kind of routing style.
Now there is one problem and that is that BizTalk is expensive, actually very expensive. Depending on the kind of application it might be enough to create a small application that just looks at XML messages dropped in a specific input queue and copies them to input queues for specific services. Again these can be simple directory drops where each service looks at or something more advanced like MSMQ or SQL Server Service Broker. A central routing application like this isn’t all that complex to develop, been there done that, and can be quite enough for a simple SOA application. Additionally an application like this can be reused in the next SOA application provided that the routing is specified in the same way or is done in a configurable way. If full scale transformations and multiple communication types are required things get more interesting and BizTalk is probably a good way to go because the amount of work and support required would be more expensive than the BizTalk route.
If you want a quick start, just go with the central drop directory and drop all messages there and have all services read from them. Just make sure you define two different directory settings for each service, an inbound and outbound, that simply point to the same directory. This way it is a breeze to add a central routing service and have each setting point to a different directory.
That leaves us with the message itself and how to add both the routing information and its payload in a reusable format, something I will cover in a
next blog entry.
There is a lot of interest in Service Oriented Applications (SOA) at the moment. Not really surprising as this architecture has a lot of benefits if used properly :-) Basically a good SOA architecture should consist of a number of different and semi independent applications (services) that work together through messages. Each service has its own responsibility, for example:
- An order entry application.
- A CRM application to manager customers.
- A financial application to register financial flows.
Now each application/service has a specified role. For example: If a user wants to enter a new order into the order entry system he/she van only select existing customers from the CRM application. When the order is complete a message is send to the financial application so the required journal entries can be made.
Now the order entry application needs to be aware of the known customers of the CRM applications. Basically there are two approaches to take here; either it requests a list of customer from the CRM application or the CRM application notifies the order entry application of new customers and the order entry application maintains its own list of known customers.
I believe the notification system is the better of the two. Why you might ask? Well for a true SOA application you want as little coupling between services as possible, you doesn’t want the order entry application to dependent on the CRM application. In fact you want to be able to replace the SOA application with a completely different one without breaking the complete system. Well broadcast notification is the way to achieve this. If the CRM application updates/adds a customer it broadcasts the fact through a predefined message. Other parts of the application like the order entry and the financial application receive this and extract the data they are interested in and save a local copy. Another part of the application, lets say the purchasing application, might not be interested in the application and can just ignore the message altogether.
So does that mean that all messages in a SOA application are broadcast notifications? No it doesn't. Suppose an order entry clerk wants to add a new order for a new order and the business allows this to happen. In that case the order entry application sends a message to the CRM application requesting a new customer to be created. The CRM application does so and returns the new customer data as well as broadcasting the fact to all other interested services.
So we basically need two different kinds of messages:
- Fire and forget notification messages to multiple endpoints.
- Request and response messages to a single end point.
That leaves us with how the route the messages. Next
blog entry more about message routing.
Maurice de Beijer
www.TheProblemSolver.nl
Today and tomorrow Microsoft organizes the DevDays in the RAI complex in Amsterdam. Lots of people are going, about 2400 I am told, and if you are come and say hi! I will be in or around the Microsoft stand in the Onyx room. There is a nice lounge area so we can enjoy a relaxing chat [:)]
Maurice de Beijer
www.TheProblemSolver.nl
I had a few questions about the article "Using the ASP.NET membership provider in a Windows forms application" I wrote about moving the membership data. In short what people wanted to was not have a local ASPNETDB.MDF SQLExpress database in the App_Data directory but retrieve the data from another, central, SQL Server.
In fact that makes perfect sense because the local ASPNETDB.MDF database is exactly that, a local database that cannot be shared between different people running the application.
Fortunately the solution is simple and consists of two parts:
- Creating the required database structure somewhere else.
- Redirecting the Membership provider to the new database.
Creating the required database structure somewhere else
To create the required database structure you can use a standard SDK tool called aspnet_regsql.exe. This will either run in UI mode if you just start it and it will simply create a complete structure in an existing database you point it to. Using command line options you get more control over what it does. This mode allows for creating specific subsets of the structure like just the membership and role tables.
Redirecting the Membership provider to the new database
Again this is easy to do. Create a connectionStrings section in the app.config file. By default the connection string LocalSqlServer is used and all we have to do is remove the original value and add a new one. Another option would be to to change the connectionStringName property when we added the AspNetSqlMembershipProvider and add that to the connectionStrings section.
<connectionStrings>
<removename="LocalSqlServer" />
<addname="LocalSqlServer"
connectionString="Data Source=.\sqlexpress;Initial Catalog=Northwind;Integrated Security=True"/>
</connectionStrings>
More Posts
Next page »