.NET

Windows Workflow

Jay Glynn — Mon, 11 Feb 2008 21:24:47 GMT

I've been digging into Windows Workflow the past couple of weeks. Very interesting stuff. Once you get your head around the paradigm, it seems to have a lot of possibilities. One thing that concerns me a little, doesn't seem to be a lot of community support around it. Perhaps I'm not looking in the right places. I'd like to see what Microsoft has in store for the future of WF. I've seen reports of it being merged with WCF, and I can see where this makes some sense but does that mean that WF is getting swept under the rug, so to speak. We're thinking of building some funtionality around it, and before I pull the trigger I want to make sure that this is something that will be viable for a while.

Composite UI Application Block (CAB)

Jay Glynn — Fri, 29 Jul 2005 15:57:00 GMT

I was able to attend the CAB training session at Redmond earlier this week. It was a very informative couple of days. We were able to meet and talk with the dev team of CAB. We went through a series of Hands On Labs that will be available soon. I am still trying to get my head around the how CAB works at a detail level. I have a good understanding of things at at a higher level.

If you are building a larger client application (non ASP) then you would be doing yourself a favor by looking at it. It is an implementation of MVC or MVP (Model-View-Controller or Model-View-Presenter). One of the big advantages that I see in it is consistency. If some dev thinks it's a good ide to put a couple of hundred line of code in the click event of button, it will stick out like a sore thumb. Another great feature is the extensibility. You can your own Services (a service provides functionailty such as persistence or cryptography) or workspaces (a container for visual items). This allows a great deal of flexibility and also allows you to create a framework that can offer a high level of reuse.

As I get more comfortable with CAB I'll try and post more about it.

Moving to v2.0

Jay Glynn — Fri, 25 Feb 2005 00:46:00 GMT

I have seen a couple of posts recently about moving code bases to v2.0 of the .NET framework when it becomes available. One that caught my eye was by Sahil. Two things struck me about the post. First the title, “.NET 1.1 Folks Please Take Note”. Aren't we all 1.1 folks at the moment. Last I looked there wasn't a go live license available yet. But more to the point is the comment about making sure your current code will work with 2.0. In the exchange of comments he made the statement to the effect that if I know the function X won't be there anymore, then I shouldn't use function X now.

Well here is my problem with this. I work in a large corporate environment. Any new technologies have to go through a long and rigorous testing process before they will be approved. So given that v2.0 won't be released until Spring/Summer of 2005 it will be at least 2006 before I could recommend it for a production application. Even then the apps that we have currently working in production won't be automatically be upgraded to run with 2.0. I can't justify the expense of re-testing and distribution for no real gain for the end user. So whether function X is available in a future version or not is irrelevent to what I doing today. I have to design for what is available today, not what might be available tomorrow. We don't even know for sure what functions will and won't be there. I have worked on 3 books based on beta .NET software and have had to make changes in all of them when they were released. Even from beta 2 to production things will change.

Just because we get a shiney new toy from Microsoft we must be prudent about moving everything we work on to the new version. Sometimes it just really doesn't make financial sense to make the move. As developers we all want to work with the newest and best technology that we can. But we also have a major responsibility to our customer to make the best fiscal decisions. I still support a lot of VB6.0 code, and will continue to for at least the next 2 years. We need to be aware of the newer technologies. I certainly am. I'm working on a book based on v2.0. But the rpoduction code I work on today is firmly based on what 1.1 has to offer, nothing more, nothing less.

Tablet PC SDK 1.7

Jay Glynn — Tue, 10 Aug 2004 06:34:00 GMT

Since XP SP2 has been released it was only a mtter of time before the Tablet PC SDK 1.7 was released. All Tablet PC developers have at it....

More on Trusted Deployment

Jay Glynn — Fri, 06 Aug 2004 01:13:00 GMT

A recent post from Mike Sampson sheds even more light on permissions and ClickOnce. It would seem that Beta 2 will make this process a little easier. The process sounds more complex then it really is. Currently in order to raise the permissions for an assembly you have deploy "something", generally an MSI will do the trick, to all of the machines. With the new method, the cert has to be done once, then ClickOnce can request the permission change on behalf of the app. I feel this to be a much better model to follow. I hope the there aren't many changes between now and release, I hate having to go back and update chapters.

ClickOnce and Trusted Application Deployment

Jay Glynn — Thu, 05 Aug 2004 21:25:00 GMT

For those that have tried to use No Touch Deployment the biggest hurdle was the security. If you install or run something from a network file share it will run with Intranet Zone settings. One of the really nice features of ClickOnce is Trusted Application Deployment (TAD). TAD uses public key cryptography to identify what is know as trust-license issuer. Once the client machine knows who the trust-license issuer is, then the ClickOnce application can be configured for a higher level of trust. It can do this without asking the user for permission. After you generate the deployment manifest you need to give it and your public key to the trust-license issuer. The trust-license issuer (this could be you as well) signs the manifest. The permission being asked for are part of this signing along with your public key. When you get the manifest back, you sign with your public key (the same one you gave the license issuer) and deploy the ClickOnce application to the file share or web server. When the client opens the deployment manifest the key for the trust-license issuer is checked. If that passes then your key is checked against the key that was used to generate the license (remember you gave the issuer your public key). Once this all passes then the asked for permissions are granted. The user nevers sees any of this happen. This adds the level of security to the process that hasn't been available. Each ClickOnce app that you deploy can have a different set of permissions with minmal effort.

Improving .NET Application Performance and Scalability

Jay Glynn — Thu, 29 Apr 2004 18:27:00 GMT

This has finally been released. No matter how much you think you know about this subject, there is always more to learn. This looks to be a good resource. I only wish they would make a format that would fit on my PocketPC. This is the kinda stuff I generally read while my son is doing his Tae Kwon Do class.