/bill's House O Insomnia : Visual Studio .NET 2005

Pro WCF: Practical Microsoft SOA Implementation

William — Sun, 18 Feb 2007 23:41:00 GMT

I went on a book binge this week and have had my nose buried in WCF all week. There's a lot of really good stuff out there, but without a doubt, Pro WCF: Practical Microsoft SOA Implementation by Chris Peiris is probably my favorite.

Overall, the book is just over 400 pages but the author says quite a bit in those 400 pages. The coolest part is that they go over just about every topic that the MSDN Documentation is short on. I found that a lot of things that I stumbled my way through were covered there as well.

I can't find the link, but a while ago, KC had a post where his server program uploaded itself his web server and ran itself. His comment was something to the effect about "What did the first Blacksmith use". I was always really impressed with that program. And not just b/c of the lower cased one's coding skill. The idea itself was really cool. So when WSE 3.0 came out and MTOM was implemented, I tried to bite his style and accomplish the same thing with MTOM. It's an easy port so it didn't take much skill on my part.

Anyway, I've been trying to figure out how to port most of the WSE 3.0 code from my 70-529 book over to WCF. I've been able to do most of it, however it's been frustrating at times. I'm make a lot of typos and copy/paste errors and neither play well with .config files. After wasting about 3 hours trying to get the MTOM port to work, I read through this book and Viola'. I was kinda mad at myself for overcomplicating things that much. So I guess I really like the book in large part b/c I've had quite a few similar experiences with it.

My favorite chapters are discussed below:

Chapter 4 - It discusses installation and configuration. This is the single most frustrating area when learning WCF. Writing code instead of using .config files is lame so I try to avoid it. But getting some help in avoiding common mistakes is priceless..

Chatper 6 discusses managing WCF Services. Not a glamorous subject but being able to monitor and troubleshoot your programs is critical. Moreover, when you're first learning how to do things, it's easy to ignore performance. It's easy to overlook things that can kill performance. After reading this chapter, I am in a lot better shape to find problems

Chaper 7 discusses security. Obviously a pretty big issue when you're building services. Just for good measure there's some CardSpace stuff at the end which was a nice touch.

Chapter 9 discusses transactions. For obvious reasons, this is a subject you need to learn well and although I thought I was pretty familiar with them, I learned more than a few things from this chapter.

-------------------

All in all, this book was pretty impressive. They do mostly real world stuff and while they certainly talk theory, they stick to stuff that you'll encounter in your day to day development. You can only take so much theory and I've found that the documentation on MSDN is really heavy on theory and not enough implementation. This book will bridge that gap. Scott Klein's WCF book will help quite a bit too but won't be out for another month or two.

I also picked up John Sharp's Microsoft Windows Communication Foundation Step by Step. So far, my impressions are quite favorable although I haven't went through it in quite the detail I did with this one. I worked through each of the examples and found them pretty cool. Should have a review of it up shortly.

I'll be doing the presentation next Monday

William — Fri, 26 Jan 2007 00:39:00 GMT

If you're going to be in Atlanta next week, stop by the .NET User Group Presentation .

As you probably know already, I tend toward non mainstream technologies. This presentation is going to be on Windows Cardspace , Windows Communication Foundation and Windows Presentation Foundation.

I've been working diligently as a tech reviewer for Scott Klein's Professional WCF Programming so I'm pretty well versed there. I've learned a lot about WCF from Scott so hopefully I can make a good showing there.
My fascination with Cardspace borders on an obsession so I'm quite confident this part should be cool.
I have 0 UI Skills so while I know my way around WPF, well, my game is pretty weak.

I was a pretty big fan of Remoting, love Web Services and loved WSE (heck, I was one of the 4 people in the world that actually cared about WSE 3.0) so WCF is just - well, da bomb. Huge move forward here.

As far as Cardspace, I can only hope it's going to get adopted and go mainstream. Self issuing cards are a cool idea and more than anything, will make things more convenient. There's got to be some streamlined distribution of Managed cards, but once that's addressed, it's got to be huge. I'm having some server problems right now, but hopefully they'll be addressed tonight. Ryan and I are putting together some web services and I hope to have Cardspace up and running with one of them.

Everybody else in the world is blogging about WPF so I don't have much to add there.

How to be really annoying with Pocket Outlook

William — Thu, 25 Jan 2007 06:08:00 GMT

If you've been following my coding tonight, you can probably tell what I'm up to. If you call me regularly, you probably are already familiar with this little project, aka the CuckooBot. He's up to Version 4.0 and about to be released into the wild. Yes, this one is more functional and useful than the last but also a lot snarkier and more annoying. In fact, he's also a lot smarter. He has a lot better AI and text parsing for one thing, so he can make better decisions about whether or not I can be disturbed and if you are on the 'cool' list, he'll actually do some of your bidding. When I release the final version, I'll provide everyone with the list of commands he'll respond to. But enough about that for now. Part two of this project involves email. You can shoot the CuckooBot an email with a request, like "Please send ClevelandSteamer.jpg" and if you are authorized, he'll send it. The authorization piece is causing me some grief but it's not like I have anything better to be doing in the middle of the night right?

Ok, so the way to send Email messages is to first create an OutlookSession object. Instantiate it and scope it as necessary. Next, specify an EmailAccount for it. Next create an EmailMessage and at the end, just Send() it.

Now, I've mentioned many times that things like BCC, CC, Importance and Sensitivity should be outlawed and considered as tantamount to war crimes for they are pure evil. But too many people like those features so I'll have to keep my little quixotic jihad against them going in other ways.

const String Primary = "Cuckoo1";

private

{

OutlookSession MainSession = new OutlookSession()

EmailAccount

EmailAccount MainAccount = MainSession.EmailAccounts[Primary];

EmailMessage MyMessage = new EmailMessage();

//One dorks set this to High.

MyMessage.Importance = Importance.Normal;

//Again, see above.

MyMessage.Sensitivity = Sensitivity.Normal;

MyMessage.Subject = "Cleveland Steamers vs. Pink Socks on Fox - 8:00 PM EDT";

MyMessage.To = new Recipient("Knights of the Cleveland Steamers", "911@clevelandsteamers.org");

MyMessage.Attachments.Add(new Attachment(@"\eviction1.jpg"));

MyMessage.BodyText = "Cleveland Steamers aren't appropriate for community sites. However I predict they'll win tonight - 9-2");

MainAccount.Send(MyMessage);

}

Password Protection != Encryption on SqlCe

William — Thu, 25 Jan 2007 03:50:00 GMT

I know this probably seems pretty obvious, but believe it or not, it's a very common area of confusion. Take a look at the following declaration:

String ConnectionString = String.Format(@"Data Source=\BlueCuckoo.sdf;password={0}", "SomeValue");

SqlCeEngine

engine.CreateDatabase();

If I asked, "Will this database be encrypted?" you should hopefully answer "No" b/c I gave away the answer in the title. However on more than a few occassions, i've seen people assume that it was. If you don't explicitly add Encrypt = True - it isn't going to be encrypted. And just in case you're wondering "Well, what if I want to encrypt the database but not password protect it?" , well, you wouldn't seriously ask me something like that right?

SMS Messages with Windows Mobile 5.0

William — Thu, 25 Jan 2007 02:40:00 GMT

A while ago, I was playing around creating a bot, a Snarkier version of the Mobile Secretary Application . Well, it was late and I got sloppy. So basically, my little app sent out a text message to everyone on one of my company's Outlook distribution lists. I learned a lot that night.

So you've always been able to send SMS messages with Smartphone, but it's a lot easier now. Sending them isn't a big deal though. The cool thing is intercepting them. To that end, the Message Interceptor class makes it quite easy:

Create a module level variable (or whatever scope you need it).

private MessageInterceptor Interceptor;

Instantiate it in the constructor

Interceptor = new MessageInterceptor(InterceptionAction.NotifyAndDelete, false);

Specify a InterceptionAction property. (Notify or NotifyAndDelete) - those should be self explanatory [See above]
Specify if you want it to use the Form's thread (a must if you want to update the UI) [see above]
Wire up a handler.

Interceptor.MessageReceived +=new MessageInterceptorEventHandler(Interceptor_MessageReceived);

Cast the e.Message object in the handler as a SmsMessage and use accordingly

void Interceptor_MessageReceived(object sender, MessageInterceptorEventArgs e)

{

SmsMessage IncomingMessage = (e.Message as SmsMessage);

String[] ImportantStuff = new String[]{"Dog pooping",

"Vista Launch",

"Would you care to explain THIS?",

"Vicodin ES",

"Camel Toe",

"Kim",

"Mom",

"EDC"};

foreach(String s in ImportantStuff){

if(IncomingMessage.Body.IndexOf(s)> -1){

SmsMessage OutgoingMessage = new SmsMessage(e.Message.From.Address, "This is the Cuckoobot, I'm handling Bill's messages, he'll be in touch shortly");

OutgoingMessage.Send();//Yes, I know this isn't optimal - it's demo code.

}

else{

SmsMessage OutgoingMessage = new SmsMessage(e.Message.From.Address, "This is the Cuckoobot. Your message isn't important and will have to wait.");

OutgoingMessage.Send();
}
}
}

A very slick Smartphone Emulator feature

William — Thu, 25 Jan 2007 01:25:00 GMT

I'm finishing up some SmartPhone articles I should have posted soon but figured I could discuss this one very quickly. Any professional application should be thoroughly tested on a physical device that it will be run on. However that's not practical for incremental builds throughout the day. So that's where Emulators fit in right? Anyway, one shortcoming of emulators is, rather was, the inability to duplicate functionality exclusive to the phone. How would you simulate an incoming call or SMS message? Fortunately, that's easily resolved now. Let's say you want to send a SMS message and test it. Just use 425.001.0001 and viola, it will fire a SMS message directly to your emulator. Just to show how easy it is...

private void SendSMSMessage(String phoneNumber, String message){

SmsMessage NewMessage = new SmsMessage(phoneNumber, message);

NewMessage.Send();

}

Then to fire it off...

SendSMSMessage("14250010001", "Behold the greatness of the Blue Cuckoo!");

More coming shortly, I promise!

Professional Microsoft SmartPhone Programming

William — Tue, 23 Jan 2007 00:59:00 GMT

I just got a copy of Professional Microsoft SmartPhone Programming and all I can say is NICE! I always worried that the first real SmartPhone book would not go into enough depth to be useful. Not an issue here. Basically, the book is a list of "What would you like to do with Smartphone" and shows you how to do it.

I need to finish reading the last two chapters before I can fully review it but having read most of it already, this book is just plain good and if you have any interest in Smartphone Programming, it's worth its weight in gold.

Musings on the database formerly known as Sql Everywhere

William — Thu, 02 Nov 2006 01:53:00 GMT

The IM volume I received today about the Rollback to SqlCE issue was enough to border on overwhelming. Between PMs and some lazy SOB CRM guy trying to get me to do all his work for him, it was hard focusing on work today. (And seriously, if you are a CRM professional, telling me you don't know how to do a two table, one field inner join so i have to do it for you, makes you look like a Complete Moron. Try 'Bill, I'm really busy, can you do me a favor and write this join for me' next time, at least then my gag reflex won't kick in). But I digress.

Anyway, I've been getting a lot of email about my presentations on Everywhere. I guess I got people thinking about a few assertions I've made. In a nutshell, I made the following comments:

I love ADO.NET and in no way am I disparaging it, but in some scenarios, the disconnected model just doesn't fit. This has nothing to do with any deficiency in theory or implementation of ADO.NET. A Ferrari is a great vehicle but if you need to tow a heavy boat, it's not the right vehicle.
The one case where I don't think the ADO.NET architectue is well suited to handle is single user scenarios where you are *positive* that you'll only have one user connecting to your database.
Devices like Smartphones and PDAs proabably aren't going to be targeting multiple users simultaneously and in those cases, where you are resource constrained and pretty much assured of a single user, the database->dataset model is overly consumptive.

In case you don't understand why, let me explain. What does using a disconnected model bring to the table? Essentially it brings tremendous scability and at least as far as the server is concerned, the possiblity of improved performance. It is a Just In Time data access strategy that can greatly minimize locking and bottlenecks. Like anything, it needs to be used wisely but the fact you don't have to keep a persisent connection to the db is huge. This benefit isn't free. In exchange for it you have to pay a price in RAM b/c you're using cached copy of the data. In most cases, this tradeoff is well worth it. In some though, it makes very little sense. Think of a Smartphone. I have one user. Only one person needs to be hitting the db at once. I have the data persisted to disk and I have limited RAM. What benefit does sticking a dataset in between my UI and the backend db bring? None.

That's where the beauty of using SqlCE/SqlMobile/SqlEverywhere/SqlCE comes in. You can use the SqlCeResultset which is scrollable and updateable, and you can cut out the layer in the middle. Your logic is trimmed down b/c updates/inserts/deletes require no work on your part provided the table you're hitting is keyed.

But that has a problem. What if the data needs synchronized with a db server? Well, you can roll your own logic. Or you can use a familiar, well documented, well tested and peer reviewed mechanism. Unless you're getting paid by the hour and you have no compunction about robbing from your clients, use the latter.

So in short, on a SmartPhone or PDA, SqlCe/SqlMobile/SqlEverywhere/SqlCe is a seemlingly perfect solution for data access. Now that you can run it on a desktop, the same holds for single user scenarios there. And using a SqlCeResultset is *not* a replacement for ADO.NET. It's still ADO.NET in every sense of the word, it's just a evolution of one aspect of it. And a darned good on for single user scenarios.

Transferring data around with ADO.NET 2.0 - SqlBulkCopy

William — Sat, 26 Aug 2006 16:03:00 GMT

I'm working at a client on a data migration and found some results that were surprising. I expected there to be a difference but not one quite this large... Synopsis of Problem: Right now I'm working on a rather complex migration from a bunch of disparate...(read more)

Could not complete the operation due to error 80041001

William — Thu, 06 Jul 2006 05:34:00 GMT

Just as an FYI about this... If you are using the documentation for WSE 3.0 and trying opening it after installing IE7 - you get an error with the following message "Could not complete the operation due to error 80041001" This is a total drag b/c all...(read more)

Do you have any ideas about preparation for 70-529?

William — Wed, 28 Jun 2006 02:30:00 GMT

As you may know, I'm coauthoring http://www.microsoft.com/learning/exams/70-529.asp . In particular, I'm covering the following objectives: Create and configure an XML Web service method. Create a public method. Attach the WebMethodAttribute attribute...(read more)

Using the SqlConnectionStringBuilder to guard against Connection String Injection Attacks

William — Sun, 15 Jan 2006 14:40:00 GMT

One new object in the ADO.NET 2.0 Library worth taking a look at is the SqlConnectionStringBuilder .

Considering how late it is in the game, you are probably aware of the dangers of Sql Injection Attacks . One the off chance you aren't, let me throw in my two cents and recommend that you familiarize yourself with them ASAP. Anyway, injection attacks are possible when you use dynamic string concatenation to build your Sql Statements and you don't paramaterize them or escape all possible malicious input. This presents a small problem b/c you need to employ user input in your applications in many cases, but every time you accept user input, you increase the surface are of an attack. And regrettably, there are too many cases where people 'solve' this problem by employing a solution worse than the problem itself. For instance, I've seen some people hell bent of using Dynamic Sql (and not parameters) solve the injection problem by disallowing all special characters. While this does address the problem directly, it has the unintended consequence of forcing the users to use less strong passwords. And most of the cases that I've seen where people implemented this rule, they increased the lenght of possible passwords to offset this vulnerability. Well, that 'solution' opens you up to other sorts of mischief. After all, if you only allow people ten characters for their password, there's only so much malicious sql they can push off on you. But assuming you don't increase the length of the password, you just pretty much hamstrung the user into have to adopt a weaker password scheme. I've bitched about this alot in the past and it's not really the focus of this article so I'll cut it short here.

So what about Connection String injection attacks? Well, yes, it's something you should guard against. When I was first learning .NET, I created this application that stored User Name/Password combinations in a Database, both of which were encrypted. This was a particularly sensitive application and I was still pretty naive about security. So I came up with a solution that entailed a good bit of extra maintenance but which I believed would give me extra security. What I did was create a Sql Server login for every user. So to even create the connection in the first place, I used their username/password combo to open the connection and then I ran an query that would check the authentication table, decrypt the username and password and pass back an output parameter indicating if they authenticated correctly or not.

This was not just a bad idea, it was terrible. For one thing, it was a nightmare to administer. Every time we added a user, I'd have to create a new Sql Server account and had to use a utility I wrote to hash the password. Other than being a pain in the neck, this made it impossible to add a new user for use with many of our applications without having to use my utlity (which people were unable to find on multiple occassions). Another problem was with connection pooling. If you have different connection strings for every user, it can have a serious adverse affect with Connection Pooling . Anyway, I thought all of this was worth it all in all b/c of the extra security benefit. Then Angel Saenz-Badillos saw a post I had that described what I was doing and he set me straight. You see, my whole concept was based on the fact that I didn't realize you could hack the connection string (don't ask me why, it should have been clear to me from the get go). But all it takes for someone to have caused some mischief for me was to add Max Pool Size 100000000; Min Pool Size 100000000 to the password field. Sure, we are used to limiting the field size in many cases for fields that we accept input from but it's not unheard of for someone to leave it the default size. Another trick that they could do is add "; Trusted_Connection = true". This will cause a 'last one wins' scenario so in the case of my app, the machine account would be used instead of the assigned user account and if it had more privileges than the user account did, well, there was just an escalation of privilege. Combined with a Sql Injection attack, this could cause some problems.

The good news is that in order to do much damage, the attacker would need to know the username and password or the machine itself would have to have sufficient permissions with the Sql Server to allow something troublesome to happen. But relying primarily on 'luck' to not get hacked is kind of a lame strategy. The other thing about Connection String Injection attacks is that if everything else is handled correctly (no unparamaterized queries allowed) then the attack surface is pretty much limited to non-permanent items or things that are just annoyances (although depending on the nature of your data, these annoyances could get quite serious very quickly).

So how do you address this issue? Fortunately the good folks on the DataWorks Team gave use the SqlConnectionStringBuilder. Basically, it handles the escaping issues for you and has the side benefit of being easier to use. For one thing you can use it just like you would you old connection strings if you're dead set on not changing your ways:

SqlConnectionStringBuilder OldSchool = new SqlConnectionStringBuilder("Data Source=Clock1;Initial Catalog=Pr0nStarz;User Id=CuckooBurd;Password=++dfjk33nmjKLLa;"); SqlConnection cn = new SqlConnection(OldSchool.ToString()); Now you can use the SqlConnectionStringBuilder just like this, it's as easy as pie:

private void DemoConnectionStringBuilder() { SqlConnectionStringBuilder ConnectionBuilder = new SqlConnectionStringBuilder(); ConnectionBuilder.DataSource = SecurityUtil.DecryptText(@"#*a0-%%% ^889333", SecurityUtil.CryptoProviders.TripleDES); ConnectionBuilder.InitialCatalog = SecurityUtil.DecryptText("pR9s4%~`"); //Here you can specify either ConnectionBuilder.IntegratedSecurity = true; //ConnectionBuilder.UserID = SecurityUtil.DecryptText("pR9s4%~`") ; //ConnectionBuilder.Password = SecurityUtil.DecryptText("!Cuck00zR~!e", SecurityUtil.CryptoProviders.TripleDES); using(SqlConnection MainConnection = new SqlConnection(ConnectionBuilder.ToString())){ MainConnection.Open(); //Do your thing MainConnection.Close(); } }
In the above example, I went with Integrated Security and commented out the username and password, but you can switch these back and forth. All of the properties like Max Pool Size, Pooling, Workstation ID, PacketSize, everything you normally manipulate is there and since you have intellisense support, you have cues as to just about everything you may need. Moreoever, if you want to be really safe, you can also create another wrapper class that exposes some of there properties but limits Max Pool Size or Min Pool Size in the accessors. For instance it could check one vs the other and if you aren't comfortable with the numbers, you can throw an exception, change them to something you like, or do whatever you see fit. Same goes for the UserName/Password and Trusted Connection. Although it will escape any attempt to try to put Trusted_Connection = true as a value, you can use your class to manually ensure that only one or the other is chosen. Right out of the Box the SqlConnectionStringBuilder is very powerful and can give you most of the functionality you'd ever want but there may be a case or two where you need everything to be even more granular - in which case you can easily implement such a scenario. Sure, as far as features go, this is more evolutionary than revolutionary, but it's a nice touch. If nothing else it will keep you from having to flip over to http://www.connectionstrings.com over and over when you are building new applications

-----

As an aside, I've listed the two primary targets for a Connection String injection attack but I'm not convniced that there aren't any other ones. If you can think of any other mischief you can cause via the connection string, be a pal and shoot me your idea - I'll include it as an addendum to this post and give you the credit.

Pimping RowState in ADO.NET 2.0

William — Sat, 14 Jan 2006 23:20:00 GMT

There are two new methods for the DataRow object in ADO.NET 2.0 that haven't gotten much coverage but can be quite useful. The two methods are SetAdded and SetModified . I consider myself to be an ADO.NET afficionado and until last week, I wasn't aware of these (yes, lame on my part). I was eating lunch with a few guys from the ADO.NET team and I mentioned to David Sceppa that it would be really cool if there was a way to manually set RowState. I've had the need to manually manipulate RowState in the past and each solution was pretty lame. Basically I'd go to the row, then change the value to itself. This was really awkward b/c well, it looks screwy. The thought of setting a variable to itself shouldn't sit well with anyone b/c with very limited exceptions, it's a totally useless operation. But when it comes to Rowstate, it was sometimes necessary. For the uninitiated, a DataAdapter object depends on Rowstate exclusively to determine what action(s) it's going to take during a call to Update. So let's say that you wanted to take the data from one table and move it to another one. The 'right' way to do this is using DTS or SqlBulkCopy (and yes, somehow I got ranked #1 on google for SqlBulkCopy ;-) ) but that's another story. Anyway, one of the other ways which was kind of a kluge albeit a pretty good one, was to set the AcceptChangesDuringFill property of your adapter to false. This would in effect fill your DataTable with rows that had a DataRowState of Added. You could then configure a second adapter, pointing to your destination table and simply call the Update method on it, passing in your just filled DataTable. Just as a note of caution - it's not typically advisable to use disconnected architecture to move data within the same database, after all you are using network bandwidth and resources that aren't necessary, but that's another issue.

Well, if you want to do manipulations like these, you were very limited in the past. That is no longer the case. With the new SetAdded and SetModified methods, you can change the DataRowState of a given row to either added or modified without having to resort to setting a value back to itself. Admittedly this is a really simple operation and doesn't need much explanation, but I figured if I missed the new features someone else might to.

private void button1_Click(object sender, EventArgs e)
{
    //Create a DataSet
    DataSet DemoDataSet = new DataSet("CuckoozDataSet");
    //Create a DataTable
    DataTable DemoTable = new DataTable("Cuckoo");
    //Add the Table to the DataSet
    DemoDataSet.Tables.Add(DemoTable);
    //Add a new Column and Set its Autoincrement property to true
    //just so that it has a value in it.
    DataColumn KeyColumn = new DataColumn("MainColumn", typeof(System.Int32));
    KeyColumn.AutoIncrement = true;
    DemoTable.Columns.Add(KeyColumn);
    //Add a row
    DataRow dro = DemoTable.NewRow();
    DemoTable.Rows.Add(dro);
    //Add 9 more so that we have 10 rows total
    for (Int32 x = 0; x < 9; x++)
    {
     dro = DemoTable.NewRow();
     DemoTable.Rows.Add(dro);
    }
    //Verify the Row Count
    Debug.Assert(DemoTable.Rows.Count == 10, "Row Count is screwy"); 

    // Verify that there are changes present
    Debug.Assert(DemoDataSet.HasChanges(), "No Changes are present");
   //Call AcceptChanges to reset the Rowstate of each row
   DemoTable.AcceptChanges();
   //Verify that there are no changes present
   Debug.Assert(!DemoDataSet.HasChanges(), "Changes are present but shouldn't be");
   //Call the SetAdded method on first 3 rows
   for (Int32 i = 0; i < 3; i++)
   {
      DemoTable.Rows[i].SetAdded();
   }
   //Call the SetModified method on the next 3 rows
   for (Int32 z = 3; z < 6; z++)
   {
      DemoTable.Rows[z].SetModified();
   }
   //Show the rowstate for each row
   for (Int32 y = 0; y < DemoTable.Rows.Count; y++)
   {
      Debug.WriteLine(DemoTable.Rows[y].RowState.ToString());
   }
   //Show output
   //0 - Added
   //1 - Added
   //2 - Added
   //3 - Modified
   //4 - Modified
   //5 - Modified
   //6 - Unchanged
   //7 - Unchanged
   //8 - Unchanged
   //9 - Unchanged
   //Verify that there are changes present
   Debug.Assert(DemoDataSet.HasChanges(), "There aren't changes but should be");
}

Misc Observations on Biztalk

William — Wed, 30 Nov 2005 15:36:00 GMT

Yesterday, to my surprise, there was quite a bit of hype about Biztalk 2006. As far as the marketing hype went, I'll go so far as to say that it was featured almost as prominently as Visual Studio 2005 and Sql Server 2005. There were a few differences though. The main one is that you got a coupon for a copy of it, they didn't actually distribute a copy of it there. big friggin deal though - most folks have it w/ MSDN or Technet and if you're using it professionally, well, then you probably already have access to it.

I've had a pretty positive relationship with Biztalk to date and think that it's really cool. I also tend the think it's tragically overpriced and has a rather schizophrenic relationship with the marketplace. Why do I say that? How many people do you know that have successful Biztalk installs and aren't scared up from getting it running? They're out there, but compared to the number of people that have problems with it, well, the ratio is fugly.

Over and over I heard/overhead the same theme - “Yeah, if you want to seamlessly map a text file to your database, Biztalk is great, but not for 50k”. Ok, that's not an exact quote but that captures the essence of it. I also heard a lot of “Ok, I see the slick demos but where are the people out there that have used it and say it's a good value?”

Now all of this is anecdotal evidence, but I didn't hear anything but glowing reviews of Visual Studio 2005. I heard almost 100% positive stuff about Sql Server 2005 - except I heard a good bit of carping about creating maintenance plans - go figure. So you have three products that are featured with approximately the same degree of prominence, and two of the products are so well recieved by the market people are giddy over them, and the other is recieved with, well, less than impressive ado. Yes, I know Biztalk is a very targeted tool not applicable to many people's day to day routines. But something just seems 'wrong' with respect to how it's recieved. Mention ASP.NET 2.0 and people are ecstatic. Mention Service Broker and people are giddy. Mention Biztalk and you hear stuff like “I can write my own tool to map a text file to my database.”

Before BTS 2004, I only knew two people that actually used Biztalk and they spoke very well of it but said it was quite a bit of work. With Biztalk 2004, I've seen both the good and the bad with it - Tobin can speak to it a little better than I can. I have a handful of friends like Scott that have used it and I know Mark does quite a bit of training with it, but that's about it.

Anyway, is it me or does BTS have a little bit of an image problem.

All Express Products will be free for a year.

William — Mon, 07 Nov 2005 23:38:00 GMT

Read on

SqlBulkCopy

William — Sun, 21 Aug 2005 22:33:00 GMT

Kim just got a new Media Center PC and I loaded the latest Visual Studio 2005 bits on it. Got a little frustrated with XPath so I took a little while away to see what's going on with the ADO.NET 2.0 Library. When I had played with the SqlBulkCopy
before, I'm not sure if I just missed it or if they weren't there but there's lots o good stuff now.

SqlBulkCopyOptions - There are 7 enum values for this and combined, they
give you an amazing amount of control over the copy procedure.

Default - Nothing special here, it just uses the default settings. As a rule, the defaults are structured in such a way that they'll do the least amount of checking. Basically, they are set at the most permissive level available.

CheckConstraints does just what it says, it verifies CheckConstraints as the data is
being inserted and if anything violates them, it yells.
KeepNulls - another real shocker here. If you have default values set on your tables
KeepNulls will cause them to be ignored.
TableLock - by default, Row locks are used as the data is loaded. This is the least intrusive
way to do an update, particularly in cases where you're dealing with a lot of data. Obviously,
if you lock the entire table, not much else is going to be done while the lock is in place.
I haven't done the performance tests yet but it looks like the reason for this is performance.
You lock the whole table but the operations go faster. This is just conjecture on my part
but if you didn't get a performance benefit, it's hard to see where you'd want to lock the whole table
in most instance.
KeepIdentity - again, this is simply another mechanism to allow you to override what the
database would naturally do. It will use the identity values that you have in place
versus generating new ones.

FireTriggers - by default, this is off. When off, none of the database's triggers are fired. When it's on, they do. Again, you probably could have guessed this without me commenting on it. Yet it's another way that you can precisely control your updates.

UseInternalTransaction - i haven't been able to verify that this actually works the way I understand it to. That probably means I'm mistaken. Essentially, you set this and each update occurs locally within the context of its own transaction. If you specify another transaction for it, an exception will be raised. That definitely works as advertised. .

-----------

There are a few other features that really allow you to finely tune your updates, most of them are very intuitve as well:

public static void Adapter() {

SqlConnection cn = new SqlConnection(CONNECTION_STRING); SqlBulkCopy bc = new SqlBulkCopy(cn, SqlBulkCopyOptions.Default); bc.NotifyAfter = 10; bc.SqlRowsCopied += new SqlRowsCopiedEventHandler(bc_SqlRowsCopied); bc.BatchSize = 100; } static void bc_SqlRowsCopied(object sender, SqlRowsCopiedEventArgs e) { Debug.WriteLine("10 More Rows have been copied, damn this is verbose!"); } NotifyAfter lets you specify an Int32 argument and after that many rows have been updated, the SqlRowsCopied event will be raised. Underneath the line where I set the NotifyAfter property, i added the event handler. Since I set it to 10, this would be pretty damn verbose in most instances, but if that's what floats your boat you can do it. Just like the BatchSize of the SqlDataAdapter, you can set this. So if you had 100 records and set this to 10, you'd have 10 trips to the db. If the NotifyAfter property was set to 10, the SqlRowsCopied event would be raised 10 times.

This is a really cool option b/c up until now, there was no 'good' mechanism for data transfer. You could always fake it by setting the AcceptChangesDuringFill property of your SqlDataAdapter to false, then use that table with a destination adapter and transfer data that way, but this was a hack and as such, was about the least efficient method to transfer data known to man. This isn't a slight on the design of ADO.NET, it's just that disconnected architecture doesn't really lend itself well to large data transfers, at least it didn't until now

2.0 Framwork Enhancements on System.XML - And misc ramblings

William — Sat, 20 Aug 2005 02:53:00 GMT

For the past few weeks, I've been upskilling as the lower cased one calls it. I'm also to get back into the groove at the newsgroups and about the only thing I'm slacking on is support over at my beloved Devbuzz which I'll be getting back into this weekend. Stuff I've been working on mainly consists of learning System.Xml inside and out (and of course XPath and XSLT), Speech Server and miscellaneous tidbits of 2.0 stuff.

The fact that I'm an ADO.NET junkie is probably readily obvious. And recently, I've realized that as much as I love ADO.NET, I've been using it as a crutch. Don't get me wrong, this has nothing to do with flaws in ADO.NET, it has flaws to do with Bill. So why is it a crutch? Well, the quote is attributed to a lot of different people, but it says essentially “He who is good with a hammer sees the world as a nail.” This is particularly true in my case. I don't think there's a problem out there that I can't solve using a DataRelation, DataTable.Select, DataTable.Compute, GetChildRows and WriteXml, ReadXml. If it's XML and I need to manipulate it, I can read it into a dataset, count the tables, count the rows in each table and start DataTable.Select ing or DataView.RowFilter ing. The problem arises when I need to get it back into XML. And what I often do is just use WriteXml and work around it (or tell guy on the other end to work around it). This is LAME on my part so I decided to cure it.

Well, that's my story and I'm sticking with it. Probably the 'real' reason I decided to learn XML is because I wanted to outPimp el Maliko in ADO.NET and I can't get there without XML. Actually, that's not the real reason either. The real reason is because theres a newly minted MVP who's notorious for convoluted and inaccurate answers and I've been reading his posts. I typically look down my nose at him with disdain b/c I think he's a jerk and his answers are either incorrect or plagairized. Anyway, every friggin XML question that pops up, he uses the same method I did. People ask about XPathIterators and he goes into 'load it into a dataset'. I was never that bad but I was close. Anyway, I'm 1/3 of my way to my goal. Right now I own a few chunks of the System.Xml namespace, XPath in particular. XSLT is giving me a little trouble, not so much with the syntax but wiht knowing what the f*** I want to transform everything to.

If you are using DataSets and you need to give people Xml in a specific format, probably the best bet is to use Xslt. From what I can tell, it's either that, or iterate the DataTables and build an XML document as you iterate them. This is a royal pain in the a33 and of very little value. Code wise it's a nightmare and if you need to change the output, you need to recompile as opposed to just editing your Xslt.

String FailoverNamespace = "williamgryan.cuckoozbackup.com"; xmlPen.WriteStartDocument(); xmlPen.WriteStartElement("Cuckooz", PrimaryNamespace); xmlPen.WriteStartElement("Cuckoo", PrimaryNamespace); xmlPen.WriteEndElement(); xmlPen.WriteEndElement(); xmlPen.WriteEndDocument(); xmlPen.Close(); 2.0 Way Now you can just use the static Create method XmlWriter xmlPen = XmlWriter.Create (@"C:\Upskilling\XML\samplecuckoo.xml"); Ok, not much different, until you look at the friggin overloads. Now you can use the XmlWriterSettings class... XmlWriterSettings docSettings = new XmlWriterSettings(); docSettings.Indent = {true/false}; docSettings.CloseOutput = {true/false}; docSettings.Encoding = 'Any value of the Encoding enumeration ie UTF16 docSettings.ConformamceLevel = ConformanceLevel.Fragment; You can set most of the behavioral settings here and then just pass it in the in the constructor: XmlWriter xmlPen = XmlWriter.Create (@"C:\Upskilling\XML\samplecuckoo.xml", docSettings);
Ok, this is a lame example I know. I'm working on a class to read through the RSS feed using some of the new 2.0 Objects. Let me finish that up and I'll post it in a few hours.

The long and short of it is though - that XML is becoming a lot more data centric, particularly in the 2.0 framework and the days of getting by withouth really being able to navigate and manipulate it are coming to an end. At least they are for me.

System.Data.FillLoadOption

William — Sat, 30 Jul 2005 02:18:00 GMT

System.Data.FillLoadOption is one of the cool new features of the ADO.NET 2.0 SqlDataAdapter. In the new framework, we have a lot more control over the inner workings of the DataAdapter and hopefully it will shed it's stereotype of being a “Black Box”. Below is the basic workings of it - nothing new here that you can't find in the documentation but I figured I'd mention it:

SqlDataAdapter da = new SqlDataAdapter(); //The current and original values will be set to the //new query values da.FillLoadOption = System.Data.LoadOption.OverwriteChanges; //The new query values will overwrite the original values. //However the current values for the row won't be changed. da.FillLoadOption = System.Data.LoadOption.PreserveChanges; //The new query values will overwrite the current values of the row //However the original values won't be changed. da.FillLoadOption = System.Data.LoadOption.Upsert;I gotta give it to the ADO.NET 2.0 team for the name Upsert. Most of the framework oozes of the Consistency Police (which is a good thing - I"m not criticising that) and this looks like a name they came up with after Happy Hour on Friday. Anyway, right now you have very little control over your Fill. Ifyou have rows and you don't have a key, calling Fill again will result in x + 1 sets of the same data. If you have a key, the behavior is different. It will look to the keyed rows and overwrite the values with the new ones. However, depending on your needs, this can be inconvenient.

Anyway, one thing I've been working on that is going VERY Slow but moving - is rewriting the Data Access Application Block to accomodate the new features of the 2.0 Framework. There's a lot there though in terms of work even though the features aren't that dramatic in terms of size (however the functionality is very impressive). What I'm saying is that the new features typically provide quite a bit of bang for the buck. If you're interested in working on this - please let me know. I'll be setting up a workspace on GotDotNet and if you're interested, please let me know.

OOP, Generics and a little Humor

William — Tue, 26 Jul 2005 00:15:00 GMT

Well, I decided to show a few examples with a little humor. I know a few of you thought my “Shocker” post was in poor taste, and I apologize if you did, but obviously many people liked it. Anyway, I'm gonig to show a few examples of how to make a class better, and better and better, and use the Shocker as an example. So at first, I'll implement it as lame as possible. Then I'll build on it and quickly show how to make an infinitely better implementation. Then, we'll actually add some smarts to it so we can make sure that only valid values can be set. I'll be using Generics to help this process.

namespace DoubleI.TheShocker { #region Using Statements using System; using System.Collections.Generic; using System.Text; #endregion class Shocker { private String _oneValue; private String _twoValue; public Shocker(String oneValue, String twoValue) { this.OneValue = OneValue; this.TwoValue = TwoValue; } public String OneValue { get { return _oneValue; } set { _oneValue = value; } } public String TwoValue { get { return _twoValue; } set { _twoValue = value; } } public override String ToString() { return String.Format("One in the {0}, Two in the {1}", this.OneValue, this.TwoValue); } } }

Oracle 10g Lite ADO.NET Adapter

William — Tue, 19 Jul 2005 03:36:00 GMT

Ok, so I read about it on Mike's as well as the Compact Framework Team but I sure can't find it anywhere. I'm probably just having a case of idiocy flare up, but I've been trying to find it for 30 minutes now. If you know where I can grab it, please let me know.