Summary: This post covers migrating a K2.net 2003 Studio Project to K2 blackpearl while documenting some of the pitfalls and how to avoid or work around them. After that I'll discuss how VB.Net support plays out in K2 blackpearl.

Converting a K2.net 2003 Project to K2 blackpearl

I'm currently assisting a client with migration of 5 processes from K2.net 2003 to K2 blackpearl.  The original processes were developed in K2 Studio (2003 product) and the language selected was VB.Net.

We're currently running K2 blackpearl 807(with update 4.8210.2.370). 

There are a few important steps before attempting project migration/conversion to K2 blackpearl:

1. Install K2.net 2003 Developer components on the developer workstation.
2. Install K2 blackpearl Developer components on the developer workstation.
3. Run K2 blackpearl Configuration tool  (happens automatically after a blackpearl install or upgrades).
   

WARNING: This should go without saying, but do not migrate your only copy of your source code, make sure to have a good backup first.

If you happened to install K2 blackpearl first and then added K2.net 2003 Studio, that's okay - just re-run the K2 blackpearl configuration tool so it can detect that K2.net 2003 Studio is installed since it is required for any code conversions/migrations.

Once the environment is setup, the migration path for a K2 Studio (2003) project is to simply open the K2 Solution file (.ksn) from Visual Studio 2005 and it will load the Conversion Wizard. There aren't any options to choose, just click on through to finish. At this point, depending on the size of your project, Visual Studio and the Conversion Wizard appears to have hung - it hasn't, it's just probably not doing the conversion in it's own worker thread so the UI will hang until the conversion process completes. Just stick around and wait, it will eventually complete.

Once the conversion completes, you will be able to view the migrated Processes in Visual Studio. To make sure the conversion process succeeded, build the project.

During my conversion, there were 300+ errors of:

"Statement is not valid in a namespace"

as well as:

class ’CDest1’ and class ’CDest1’, declared in ’C:\Documents and Settings\<userId>\Local Settings\Temp\ExtenderProjects\VBWinWF-c48c272384ac409dbf74701679ef6f65\DestinationRule_339d5b93cc814379b085361f550f7d4b.vb’, conflict in namespace ’<Default>’. 

or even:

Expected class, delegate, enum, interface, or struct C:\Documents and Settings\<userId>\Local Settings\Temp\ExtenderProjects\CSWinWF-f3967973aafd4628aecca3469dbb4015\EventItem_e961c0616b7f46698827937752b6a0fb.cs 5 8 VSCSWinWF-f3967973aafd4628aecca3469dbb4015

These sorts of errors indicate a failure to convert properly and you should contact K2 support and request the following Hotfix:

KB000400 - Hotfix: K2 Designer for Visual Studio is unable to compile a project that contains a K2.net 2003 Artifact(s)

If you require the HotFix you'll need to install it and then restore your original K2.net 2003 project and re-convert. Once these errors are cleared up, anything remaining are most likely project references that need fixed.

Once all the code has been migrated and you can build successfully, there are a few additional things to consider if you are hoping to use VB.Net - the next section will cover that.

VB.Net Support in K2 blackpearl

A Quick Bit of K2 Compatibility Terminology
In K2.net 2003, Processes contain one or more Activities which contain one or more Events - when designing workflows in K2 Studio 2003, the Activity and Event Controls live in the Toolbox in K2 Studio and are called Templates (Activity Template and Event Template). In K2 blackpearl, Processes are still made up of one of more Activities which contain one or more Events, however they have changed the name from Template to Wizard. The Titles in Visual Studio Toolbox reflects this - if K2.net 2003 is install, you should also see the K2.net 2003 Templates in Visual Studio as well.

Compatibility in K2 blackpearl and K2.net 2003
If you've spent any time with the new Visual Studio K2 blackpearl extensions, you may have realized that there's no place to choose a language choice like there was in K2 Studio 2003 (vb.net or c#). This is not a mistake - currently all of the K2 blackpearl Wizards generate the underlying Workflow Foundation (WF) and Event Item code-behinds in C# only.

When converting K2 Studio 2003 VB.Net projects to K2 blackpearl, compatibility is maintained by using legacy K2.net 2003 Process, Activity and Event Templates within Visual Studio 2005 - this means that as long as you are in these Templates you can use VB.Net code within your processes. Additionally you can mix in the new K2 blackpearl Wizards in the process as well, but these will use C#.

This means for any Process based on a K2.net 2003 Templates, you can combine K2 blackpearl Activity and Item Wizards, however the one limitation is that you cannot have both a K2.net 2003 Event Item Template and a K2 blackpearl Event Item Wizard in the same Activity.  This is because Activities are either based on the K2.net 2003 legacy Activity Template or the new K2 blackpearl Activity Wizard and you can only put like Events within an Activity.

Likewise - the same applies for a K2 blackpearl Wizards - K2.net 2003 Activity Templates and Event Item Templates can be mixed in a K2 blackpearl template, but not within the same Activity and to reiterate - all K2 blackpearl Event Items ONLY support C#.

Additionally - if you want to use VB.Net (or any other .NET language for that matter) as much as possible with K2 blackpearl (without using the K2.net 2003 Templates), then add another project to your Solution using the language of your choice and then add a reference to it in your K2 blackpearl Process. Then when when writing code, minimal C# code will need to be written to make calls to your VB.net library. Not necessarily perfect for a VB.Net purist, but it comes pretty close.

If you do not see the K2.net 2003 Templates within the Visual Studio Toolbox or if you want to import custom templates from K2.net 2003 to use within K2 blackpearl, see the following webcast by K2's famous Chris Geier for how to import the K2.net 2003 Templates: Using 2003 Templates in blackpearl

Please share your questions, comments, experiences with Migrations and converstions in the comments! I'll do my best to respond.

Over at [Security Through Absurdity] I've posted the first in a series of articles that will explore the most common vulnerabilities and the mind-set of the developers that create them and also explore how to deal with them. The first post in the series takes a look at the OWASP top number 2 vulnerability, Injection (specifically SQL Injection) - which has been a known and solved problem for over 10+ years, yet for some reason, it's still as common as ever.

While not necessarily K2 specific, the principals definately apply to all areas of programming. Check out the article here. Feel free to share your experiences in the comments as well.

Our hard work has paid off and the book is now in stores.

"Built on Microsoft technologies including Microsoft Office SharePoint Server, SQL Server, Microsoft Office 2007, and Visual Studio 2005 and 2008, the latest K2 [blackpearl] release provides you with mature workflow management systems that can automate processes or pull together people, services, and systems. You’ll get an introduction to workflow and business processes management, planning and administering a K2 infrastructure, and building processes and workflow."

1. Bug decompressing DNS Labels when resolving any DNS name. This only tends to pop up more when there were a lot of query results for a query. It turns out I was truncating six of the most significant bits of the byte pointer offset when unpacking the DNS labels.


2. A few cast errors in the SrvRecord class had the Port and a couple other properties always returning zero.


3. Finally, I added a UDP Socket timeout so that the socket wouldn't wait forever before timing out if the server wasn't responsive.

Related to my recently released DNS Client library, DnDns, I’ve finally gotten around to releasing a SMTP client library.

This SMTP library provides basic SMTP functionality – it’s able to deliver emails with multiple text mime parts and a few different types of attachments – adding additional attachment types via code should be trivial.

The one main benefit DnSmtp provides over the native .NET Mail implementation is the ability to deliver mail messages directly to the recipient’s email server. It does this by doing an MX lookup (using DnDns) on the email recipient’s domain name and then connects directly to that server to deliver the message. This, in some cases, can provide additional verification of whether an email was successfully delivered to the destination.  This doesn’t work in all cases though -some email systems, like qmail, accept all email messages and then bounce them back if the account doesn’t exist locally.

One area where it falls short from the .NET 2.0 implementation is the ability to encrypt emails.  This is a feature I’d like to eventually add, time permitting.

This SMTP library was originally conceived back in 2001 when we needed to send email from one of our web servers – and we discovered we needed to install Outlook in order to get the .NET 1.1. email functions to work properly, apparently MS decided to have code dependencies that weren’t included in the OS – they have since fixed this in .NET 2.0.  I had some spare time so I started putting this library together. It’s gone through a couple iterations since them, but it’s mostly the same at its core. Since this library is around 8 years old, it’s a bit rough around the edges and looking at it again, I can see many areas for improvement as well as new important features to add.

For now, I have released it as is on CodePlex under the New BSD license. As time permits, I hope make some enhancements to it.

If you happen to use DnSmtp, please report any bugs and/or feature enhancements to the DnSmtp CodePlex site. You can download the source or binary dll here:

DnSmtp – A .NET SMTP Client Library

You’ll also need the DnDns library - DnSmtp is dependent on it.

I have been a fan of OpenDNS for a while - it is an excellent free service that will bring an additional layer of security to home and small/medium business networks at the DNS level by providing content filtering, phishing protection, domain blocking, adult site blocking, web proxy blocking, domain white-listing, and typo correction. They also claim to reduce the possibility of cache poisoning and pharming "due to its unique handling of DNS requests and multiple levels of validation applied to all DNS queries."1

Additional features (non-security related) include domain shortcuts and a very LARGE cache for speedy name resolution

The only trick (if you want to call it that) to receiving the all the features of OpenDNS is that they need to know your current public IP so it can be associated with your specific OpenDNS settings - this is simple if you have static public IP, but if you are assigned a dynamic IP you have to have a mechanism to notify OpenDNS of your current latest and greatest public IP. This is important whether at home or if you're out and about with your laptop on other public networks where the DNS servers may have been poisoned/hijacked/pharmed.

Because of the need to keep track of your changing public IP, OpenDNS created a service called DNS-O-Matic. DNS-O-Matic's purpose is to allow routers and software clients to notify them of your current public IP and they, in turn, will notify OpenDNS so your settings can follow you. However, DNS-O-Matic didn't just stop there, they also support notifying a myriad of other services that your IP has changed as well - services such as DynDNS, NO-IP.com, and of course OpenDNS. I think last I counted around 29 different services they will update for you.

I briefly looked at the API documentation for DNS-O-Matic and it really couldn't be any easier - it's a basic HTTP GET request with some URL parameters. With this information in hand, I decided to take a few hours on a weekend and bang out a Windows Service in .NET. It doesn't support all of the features of DNS-O-Matic (i.e. Dns-O-Matic will update MX records and other types of things the other services support), but this service supports the core one - updating your changing IP.

I took a few snippets of code I have found on various sites on the Internet and others techniques I have come up with and brought them together in this service. If you've never written a windows service, this would be a great project to take a look at as a primer. Things such as:

1. Setting up a Windows Service Recovery Options programmatically and other Windows Service tricks in .NET - props to Neil Baliga's project titled "A ServiceInstaller Extension That Enables Recovery and Autostart Configuration" on codeproject.com.
2. Changing a Windows Service DACL's to limit users' ability on the local system to stop/restart a service (via p/invoke - thanks to pinvoke.net)
3. Using the System.Threading.Timer in coordination with the System.Diagnostics.StopWatch classes.
4. Using the System.Threading.AutoReset class.

At least one of these I plan on blogging about in more detail at a later date.

Anyway - enough of the chatty-ness...I've listed the project as OpenSource on CodePlex under the New FreeBSD License:

DNS-O-Matic Sync Service for Windows

This week I finally have had some time to take a look underneath the Membership and Roles infrastructure in ASP.NET 2.0 and have a significant update to the ASP.NET SmartCard HttpModule coming in the next couple weeks, as well as some necessary additions.

A preview of this update:

1. SmartCard support under the System.Web.Security.Membership class
2. SmartCard support under the System.Web.Security.Roles class
3. Support for the SqlRoleProvider (with the SmartCardSqlRoleProvider)
4. How to provide auto-enrollment and manual enrollment of Smart Card users into your application.

I'll also provide some behind the scences with the RolePrincipal Class and how it works with the SmartCardIdentity and SmartCardPrincipal classes...

Stay tuned!

I've been sitting on the source code for a DNS resolver library I wrote for a few years now, wondering what to do with it - and too busy to really think much about it anyway. Finally I've decided to release it on CodePlex under the new BSD License for others to learn from and use.

It was originally done using .NET 1.1 - I've ported it to .NET 2.0 - though there is no real differences between the two versions. It is a fully managed implementation written in C# - I suspect it will run just fine on Mono since there's no specific MS Windows namespaces required...but I haven't had time to try it out yet - if anyone has a chance to try it out, let me know how it goes.

The project on CodePlex is located here:
DnDns - A .NET DNS Client Library

Doing a standard 'nslookup' on www.google.com would be done like this in code:

To do a normal Host (A) lookup:

1 DnsQueryRequest request = new DnsQueryRequest();
2 DnsQueryResponse response =
3 request.Resolve(dnsServer, "www.google.com",
4 NsType.A, NsClass.INET, ProtocolType.Udp);

To lookup Google's gMail MX record for email:

1 DnsQueryRequest request = new DnsQueryRequest();
2 DnsQueryResponse response =
3 request.Resolve(dnsServer, "gmail.com"
4 NsType.MX, NsClass.INET, ProtocolType.Udp);

To get the answer, loop over the response.Answers[] array...you can also inspect all aspects of the DNS record response (headers, answers, additional records, etc.).

Motivation

I enjoy implementing protocols. My first network protocol I implemented was a Quake 2 server browser in Java - you could find Quake servers on the Internet and also check out the score of a game that was in-process from a particular server (very similar to early versions of GameSpy Arcade). After that I was hooked - leaning the internals of how the Internet functions is fascinating to me.

I went on to implement a FTP client, a native SMTP mailer (the main reason being that .NET 1.1 required Outlook/CDONTS installed to handle SMTP which was overkill of a requirement), a Syslog listener for keeping tabs on my Firewalls, FreeBSD Servers, and routers - which I'm also working to release soon as a part of another project I'm working on (stay tuned), and the protocol of this discussion, DNS.

In retrospect, the DNS client was probably the most interesting protocol to implement. It's clear the goal in the DNS protocol was to be very light weight and to utilize very little bandwidth. I enjoyed seeing how these efficiencies were implemented in the protocol back when a bandwidth was not as available as it is today.

It's not simply because they choose originally to use datagrams (UDP) that makes the DNS protocol light weight - though that's part if it - it's how the data is packaged for transmission. If that sort of thing interests you, check out section 4.1.4 titled "Message Compression" in RFC 1035. It is an incredibly simplistic type of compression...to reduce repetition of domain names in the message, they stored pointers throughout the message that point to previous occurrence of the same name so names are never duplicated within a message. It's surprising how little space this seems to save, but I suspect every little bit of savings were important back when the system was originally created.

Below is a list of the RFC's I used to implement the DNS client library (as well as Ethereal which was indispensable of course):

• RFC 1034
• RFC 1035
• RFC 1183
• RFC 1464
• RFC 1876
• RFC 1886
• RFC 2052

I may be missing a couple - it's been a while since I've reviewed the RFC's for which NSTYPE is in which RFC...of course there are some new features in DNS I'm interested in adding, specifically the DNSSEC record types.

Again, here's the link to the DnDns project on CodePlex:
DnDns - A .NET DNS Client Library

Samples are provided on the CodePlex site. Feedback, problems, and suggestions are welcome.

Recently I ran across a pretty odd issue on an ASP.NET web site that I was able to work through. 

Setup
1. Internet Explorer
2. Smart Card Authentication with SSL/TLS
3. ASP.NET 2.0 web site running on IIS 6.0 on Win2k3

Symptoms
When using the web site, users complained that at certain points when using the site, they would click on something and the page in IE would go 'white' - the page would look exactly like the 'about:blank' page. While not necessarily a very technical name, it was certainly descriptive of what was happening.

After trouble-shooting further it was determined that the page only went white after the user left the web browser sit for a couple minutes. Then when the user did a POST, the page went blank.

At this point the cause was speculated to be anything from a piece of networking equipment (a proxy?) between IE and web server, to the web server itself, to the .NET web application (depending on who you asked).

Troubleshooting
My first goal was to duplicate the problem on my system and I was able to reproduce it as described in MOST cases, but not 100% of the time.

Next, on the blank page, I did a "View Source", turns out it had  the entire contents of the previous page before the POST occurred.

Out of habit I saved the HTML source and check it's file size...the page was over 1MB.  Turns out the developer isn't managing ViewState properly with a GridView.  My initial thought is that this is worth pursuing as the root cause.  I did the same test on a page with a small ViewState and the error did not occur.

So at this point, I think I know what the solution is, but I don't know what the actual problem really is, so there's more work to do.

Next I pull out Fiddler, a HTTP debugging proxy - even though the ViewState is large, IE should still be able to render the page so I want a lower level look at what's going on. There's also this strange timing issue where the bug only occurs after two minutes. After firing up Fiddler, loading the first page then waiting two minutes before POSTing more data, the following HTTP error is reported in the Fiddler output.

HTTP/1.1 413 Request Entity Too Large

This error message didn't immediately reveal what the issue was - only after some extensive searching that combined the "HTTP 413 Request Entity Too Large" error combined with search terms related to Client Certificates did the appropriate Microsoft Article actually come up.

The REAL Issue
This issue is a problem in the underlying protocol (SSL/TLS) authentication specification; this is not a Microsoft or an IIS problem nor is it necessarily a developer problem as long as care is taken to keep certain “features” of ASP.NET in check. This problem will show up on any web site that attempts to do an HTTP POST with a large amount of data to an IIS web server while at the same time, re-establishing the SSL/TLS encrypted channel (HTTP CONNECT). This is why this particular problem is seen only after allowing a period to pass.

This problem is typically seen when uploading files to a web server and rarely seen when submitting a HTTP POST of Form variables, because rarely do they need to be larger then a few kilobytes.

According to Microsoft Technet article on this issue:

“If client renegotiation is requested, the request entity body must be preloaded using SSL preload. SSL preload will use the value of the UploadReadAheadSize metabase property, which is used for ISAPI extensions. However, if UploadReadAheadSize is smaller than the content length, an HTTP 413 error is returned, and the connection is closed to prevent deadlock. (Deadlock occurs because a client is waiting to complete sending a request entity, while the server is waiting for renegotiation to complete, but renegotiation requires that the client to be able to send data, which it cannot do).” [1]

To summarize, the UploadReadAheadSize metabase property in IIS 6.0 needs to be large enough to load the SSL POST entity body such that on Client Certificate (CAC) renegotiation, a deadlock does not occur.

It would be unwise to increase blindly the UploadReadAheadSize metabase property without consideration of the consequences (it has a max value of 4GB). If the size is set too large it becomes an attack vector for Denial of Service attacks (DoS) since we might exhaust resources on the system.

The default size for UploadReadAheadSize metabase property in IIS 6.0 is 49,152 bytes.

The Solution
The solution to the problem is not necessarily to just increase the UploadReadAheadSize site limit as you will always be able to create a page on a web site that will cause this problem unless you increase the POST size so large as to create a security issue that creates the DoS situation. The best way to remediate this problem is to reduce data POST sizes when possible instead of playing a guessing game with the UploadReadAheadSize metabase property.

With this in mind, Developers must familiarize themselves with ASP.NET best practices as they apply to ViewState size especially in any DoD environment which requires Client Certificates (CAC / Smart Cards) for authentication making a non-issue, an issue. Dino Esposito, an authority on ASP.NET development, has some information on the topic of recommended ViewState sizes here: ASP.NET 2.0: ViewState Numbers. He recommends ViewState not exceed 7KB. My personal view is that his number, in some cases, might be a bit conservative. I take the stance that the ViewState size should not exceed the size of what the industry has deemed acceptable optimized image size that can reasonably be displayed on a web site. This number is often greater then 7KB as rarely is it an issue to download an image of even 10 KB to 20 KB, but that’s on the very high end and is probably a bit excessive for ViewState especially if your web site is already graphics intensive.

Now the fact that Internet Explorer just displayed a blank page when encountering a 413, I think could be classified as a bug. Reporting the "HTTP 413 Request Entity Too Large" error back up to the user seems appropriate.

[1] - Client cannot renegotiate request and returns an HTTP 413 error (IIS 6.0)

  NOTE: This KB article seems to have a mistake:
  cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 200

  Should read:
  cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 204800

According to the IIS documentation, the argument is in bytes - not in kilobytes. See UploadReadAheadSize Metabase Property in the Microsoft IIS 6.0 Reference.

I just finished up a SQL Server 2000 to SQL Server 2005 upgrade on a large fail-over production cluster. I ran into a couple of issues that extended the upgrade outside the maintenance window and caused me some serious headaches. This may save you some time and sanity before upgrading your SQL Server Fail-Over cluster from 2000 to 2005...

Read the article