Dynamics CRM 3.0 - August 2007 Virtual PC Image

We've been waiting for some time to get the new Dynamics CRM 3.0 Virtual PC Image. We can download it now on: Microsoft Dynamics CRM 3.0 Virtual PC Demonstration - August 2007 Release What's in this Release?
  • Windows 2003 R2 SP2
  • SQL Server 2005
  • Internet Explorer 7
  • Office Professional Plus 2007
  • Office Sharepoint Server 2007
  • Dynamics CRM 3.0 (V3C, Rollup 2)
  • Dynamics CRM Laptop and Desktop client
  • Dynamics CRM SDK
  • Dynamics Web Parts
  • Visual Studio 2005
  • Windows Desktop Search 3.01
  • POP3 Services (no Exchange)
Hmm reading this. What about Visual Studio 2005? What's the use of it, development for Dynamics CRM 3.0 needs to be in .NET 1.1. I know it is possible to use Visual Studio 2005 to target to .NET 1.1 but it isn't that easy. I'm going to download the image as soon as possible and maybe add some comments to this post as part of it.

My view about the overview of Microsoft Visual Studio 2008

Microsoft published a white paper about Microsoft Visual Studio 2008. I read it and discuss it in a brief summary. The white paper discuss the different customer experiences that Visual Studio 2008 delivers through seven different technology areas.

  1. Develop Smart Client Applications
  2. Create Microsoft Office Applications
  3. Build Windows Vista Applications
  4. Handle Data More Productive
  5. An Improved Developer Experience Overall
  6. Enable New Web Experiences
  7. Improve Application Life-cycle Management (ALM)

1: Develop Smart Client Applications

The ClickOnce application deployment is improved. Firefox is supported as a browser, very nice and necessary for ClickOnce becoming successful.

Something I'm not really sure about. Office 2007 UI support for native C++ applications. Those native applications can make use of the Ribbon Bar, Ribbon Status Bar and Mini-toolbar. But why only support native C++ applications? We want this feature for managed C# applications, don't we?

Microsoft Synchronization Services for ADO.NET provides an API to synchronize between data services and the local data store. This could be nice, but I hope it's solid. In the past I sadly met Microsoft Access Replication, something comparable to the basics I think. I'll never suggest a company to use Microsoft Access Replication. But ADO.NET Synchronization Services might work, I guess we will have to wait for Real World Experience on this.

2: Create Microsoft Office Applications

No comments yet, maybe later.

3: Build Windows Vista Applications

Visual Studio now provides tools for Windows Presentation Foundation. We can now use a designer to create our user interface, in the past we needed to use Microsoft Expression Blend.

4: Handle Data More Productive

Also new is the Language Integrated Query (LINQ). It supports querying for objects, databases and XML. And if I'm right LINQ 2 SQL is some sort of ORM tool. I try to look more into this in the future.

5: An Improved Developer Experience Overall

You have the ability to target different .NET Framework platforms while making use of Visual Studio 2008. Very nice, I'm not sure how far this goes. Are you able to build against the .NET Framework 1.1 but are you able to make use of IntelliSense trough the other platforms? Are you able to make use of designers for the .NET Framework 1.1? Don't think so, but I have to check first.

6: Enable New Web Experiences

The new web experiences consists of the integration of a new version of AJAX ASP.NET and the integration of Windows Live Services. Besides this it should be easier to consume a Windows Communication Foundation service.

7: Improve Application Life-cycle Management (ALM)

The most interesting thing is the enhanced Visual Studio Unit Testing. The performance is improved, but I'm interested to see if it is extendable and be used better in conjunction with Mocking frameworks.

Sharepoint Workflow Runtime Safe for Escalation Workflow?

When working with Workflow it is possible to add a waitfor activity to build some sort of Escalation mechanism. Very interesting, and often used I would say. But when using Workflow Foundation you must be reminded that Workflow instances will only run when the Worflow Runtime is running.

This is very interesting in standard ASP.NET scenario's. Most of the time you will choose to host your Workflow runtime in one of the ASP.NET processes. At first this doesn't sound like a problem. But have you ever noticed your ASP.NET processes are recycled after some inactive time? This won't happend on a ASP.NET application with heavy traffic, for every minute in a 24-hour day. But a lot of companies have ASP.NET Intranet applications, which are active for some time during the day, and inactive during the night.

When hosting your Workflow Runtime in your ASP.NET process this will make sure your Workflow Runtime will be recycled during the night. So there must be a mechnism to make sure your Workflow Runtime doesn't stop. Because a stopped Workflow Runtime means no running Workflow instances. You can use a Windows Service to leverage a Workflow Runtime, but communication with a Windows Service from inside your ASP.NET application isn't that simple. But we are allowed to make a choice for this, what would we want.

But how does this work in Sharepoint 2007?

I couldn't find an answer to this. At least not directly. I found an article about how to debug your Workflow instance that is hosted by the Sharepoint Workflow Runtime. This article explains how you can debug your Workflows inside Sharepoint. You are instructed to attach your debugger to the w3wp processes, the standard processes in which ASP.NET operates. This asumes to me that the problem described also exists in Sharepoint. But can anyone assure that the Workflow runtime is hosted on the w3wp process?

Sharepoint EventReceiver ending recursion

In Sharepoint the majority of date is stored in so called lists. It is possible to listen to events on a specific list by using a custom C# class. The events you can listen on are: Adding, Added, Updating, Updated, Deleting and Deleted. After you receive such a event you can use the data and do all sorts of things with it. It is possible to create a so called event receiver by extending SPItemReceiver and overriding the events you want to handle. One of the possible events you can listen to is the ItemUpdated event. But from my experience with Microsoft Dynamics CRM 3.0 I know there are some important things to keep in mind before using the ItemUpdated event. In a Dynamics CRM enviroment you must 'never' update the item from which you receive the Updated event. I say 'never', but there are some situation in which it is allowed. But for all situation be carefull, because updating the item for which the Updated event was caused will cause a new Updated event. This will result in a 'never' ending Recursion. Yesterday I was thinking about this in the Context of Sharepoint Server, and together with Alex Thissen we tried out to be sure. We found out that the expected never ending recursion ended after 10 times. I'm not sure about the implementation for this, but I'm sure Microsoft did some tricks to make sure 'never' ending recursion do no occur. So, now I know this: Can I stop worrying about 'never' ending recursions? I don't think so, because the following situation isn't exactly what you would expect. For example: We listen to an Updated event for a buglist, and as a result of this event we send one e-mail out, and update the status field of the bug. What I would expect: An updated status field on the changed bug. And one e-mail send out. What I would get: An updated status field on the changed bug. And ten e-mails send out.

Mastering InfoPath Development

It was just last week when I was thinking about buying a book about InfoPath 2007. At this moment there aren't very many books about InfoPath 2007 (I only found one), so I thought about googling before buying. I found out about a series of articles about mastering InfoPath Development.

The series consists of the following articles:

I haven't read them all yet, but they seem a good start for building up InfoPath knowledge.