I am currently working in Beta 2 of Visual Studio 2010
with version 4.0 Beta 2 of the .NET Framework.
The first thing I’ll have to note in working with the Beta 2 samples in Windows Workflow Foundation 4.0 is that you’re not going to survive the sample as a passenger – at least not without a few notes on running it.
If you want some tips on what the app is supposed to do, head to the end of this post.
The description of the sample is still a little lacking, which is understandable considering it’s in Beta.
You’ll likely find this on your own, but the script required to run the application must be run from a command prompt with .NET environment variables loaded and run in a context with administrative privileges.
The HiringSample solution out-of-the-box does not work on 64bit systems because of the build settings.
Further, you’ll need to be aware of the service endpoint collisions that might occur if you try to debug from the a normal F5.
Lastly, I found that I had to manually create a folder used for request history in the data folder in order to get the application running.
Let’s start with the admin and 64 bit issues.
Configuring the DB and Loading the Services
First off, you need to get a prompt running with the .NET 4.0 environment variables set up. In Vista or in Windows 7, simply hit your start button and type in “2010 prompt” (without the quotes) and it should be the first thing on your list. If you need to locate it manually, check in Program Files –> Visual Studio 2010 –> Visual Studio Tools –> Visual Studio Command Prompt (2010).
If you can’t find the prompt as a shortcut installed to your machine, check out my earlier post for that.
Next, navigate to the [samples root]\WF\Application\HiringRequestProcess\CS directory. In there you’ll find the setup.bat and startservices.bat files. Run setup.bat (this should be the only time you need to do this).
Next, open the HiringProcess.sln and build it (don’t run).
Pop back over to your command prompt and run the startservices.bat file to get everything fired up.
If you get an error at this point it may look something like this:
System.BadImageFormatException{"Could not load file or assembly 'HiringRequestProcess, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."}
You may not see the error without attaching a debugger (or trying to run the project directly from the debugger) but I did get this message while trying to build. To get around this – and again, I am on a 64 bit machine – I changed the HiringRequestProcessDefinition to target x86 machines (the HiringRequestProcess DLL project is set to target x86 and it is a dependency of the Definition project). This allowed me to build the service projects and run them from the command prompt.
I initially made some progress and was able to get everything to compile by changing HiringRequestProcess to x64 and recompiling…except the web site, which starts throwing the same error as above.
Resolving DirectoryNotFoundException
The next bit was a little more tricky to get going. You can’t debug the WebClient project directly through the solution as you get a host of other errors (endpoints already exist) with the WCF services. This was a red herring of sorts as I tried to chase the other peripheral problems.
The issue at this point was that, while I could use the web site, persistence was not working and errors were not being reported to the WebClient.
I launched the web application per the instructions (right-click on the project, view in browser) and then attached to the process. I also attached to HiringRequestProcessDefinition, which is where the XML persistence was failing. This allowed me to expose the said exception.
To resolve this issue, simply add a directory called RequestHistory to the Data directory in the solution.
A Sample Overview
I couldn’t find a document that described the projects in any level of detail, so I’m writing a quick summary that it might help someone out there.
There are five projects in HiringRequest solution, the first listed in Solution Explorer being the WebClient.
WebClient has references to HiringRequestService, InboxService and OrgService, the three services that drive the overall project. The web site is set up with a drop down box
InboxService has methods needed to fill out the default view in the web client as well as add and remove methods for inbox messages.
The OrgService is the human resource component of the application and handles pulling up corporate roles, lists of employees or specific employee details. These are all readable with no write functionality. The employee list and all supporting data is loaded on demand when the service is called and is not cached.
Note that in the solution OrgService and the IOrgService interface live in files named HRService and IHRService respectively.
The HiringRequestProcessDefinition is the last stop on the tour, along with its dependency on HiringRequestProcess. HiringRequestProcess contains the repository for requests and some base classes and constants used in the application. The Definition project is actually two-part: the WF diagram (declarative) definition of the workflow and the HiringRequestProcess service.
A Few More Tips…
Make sure you read the MSDN help on getting the app to run. There’s a lot said there that I didn’t say again.
If you set up the database on a non-default instance (meaning, if you’ve changed the default name of SQL Server Express on your machine) you’ll need to update the connection string used by the service in the HiriringRequestProcessDefinition project. You will get a confusing, misleading error if you don’t. It is located in app.config as the second group of entries.
When you’re using the web client, there is a drop down box that lets you change who you’re “logged in” as. There is no login procedure other than changing the dropdown.
Make sure you keep the service windows open and in view when running the sample. Someone in the organization of a certain role must act on hiring requests per the business rules and org structure. The service console windows give you hints (employee ids) on who needs to do something next.
Hope this helps some! Best of luck in exploring Windows Workflow Foundation 4.0.
No comments:
Post a Comment