BizTalk Hosted Web Service - Error CS2001

The project that I am currently on has an Orchestration that is exposed as a Web Service. This is running on Windows 2003, so we have created an app pool and assigned the BizTalk Isolated Host Instance user to this app pool's identity.


We just migrated our app to a pre-prod environment and were having some troubles connecting the client application to the BizTalk exposed web service. There were no errors in the event viewer on the BizTalk server, but there was in the client application's event viewer.


Here is the error:
Problem while generating request for waiting records: Server was unable to process request. ---> Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\hgz0bwpr.0.cs' could not be found
error CS2008: No inputs specified


There are a fair amount of CS2001 and CS2008 errors documented on the web, but I figured I would add this one to highlight that the error occurs on the client machine, not the host server.


How did I fix it?
I provided the BizTalk Isolated Host Instance user with the following permissions on the C:\Windows\temp folder:

• Read & Execute


• List Folder Contents


• Read

Also note that this machine is internal to our network so if your machine is externally facing, you may want to further restrict some permissions.

PDC Day 4 - More time spent in the Cloud

On the 4th day of PDC I spent more time in the Cloud learning about some architectural scenarios that the Cloud is capable of supporting.

As part of the PDC Symposium series, I attended Gianpaolo Carraro's session called "Head in the Cloud, Feet on the Ground". The objective of this session was to further investigate the Architectural challenges and opportunities in the cloud.

I found this session to be really helpful as so much of the other sessions has been about the technical bits that makes the Cloud technology "cool". This session focused on decisions that an Architect or even CIO may face when thinking about what applications belong in the cloud and which applications may be better hosted on premise. On premise meaning locally in your organization.

He also attacked this subject from two perspectives:

1. Corporate IT perspective
2. ISV Perspective

Since I live in Corporate IT I will spend more time in this area.

On Premise
Applications that are hosted locally tend to have more control than those in the cloud. Think of this more in terms of a custom application versus an application that runs in the cloud like Salesforce. If you have a custom built application, then your organization controls the feature set and have more agility when making a change as less people are involved. A challenge with this approach is that you have very little economy of scale as only your organization can extract value out of this application.

Cloud Applications
Conversely, an application that runs in the cloud has an opportunity for great economy of scale. Since many customers may be paying for this application, the savings are returned to the customers as collectively they are paying for the software to be developed. The challenge with this approach is that a company may need to alter an internal business process to align with the way that the application has been designed.

Conclusion
The end result came down to determine which applications are core to your business and provide a competitive advantage. These are the types of applications that are ideal candidates to be built and hosted internally. The commodity applications like Mail Services or Timesheet applications that are required to run your business, but not necessarily make your business more competitive are candidates for cloud based applications.

Best of both worlds
What I find extremely compelling is the idea of building an on premise service, yet leverage the capabilities of the cloud to expose this service to the world. This alleviates you from being overwhelmed with challenges related to Firewalls, NATs and security. I find this of even of greater value when you introduce several B2B partner scenarios. You don't need to be concerned with each of your partner's connectivity requirements. You let the .Net Service bus deal with those complexities.

Co-location
Also worth mentioning is a middle ground called Co-location or Managed Servers. This type of scenario may be ideal for you to build a custom application, but have it hosted by a 3rd party where you are not responsible for the on-going maintenance of the server that is hosting your application. For instance you may be a small or up and coming company that just does not want to make a large up front investment in infrastructure, but want to build an application and have it hosted in an external environment. This allows you to reduce the amount of up-front Capital Expenditures.

Looking Ahead
While some of this discussion is nothing earth shattering or ground breaking, I am curious to see how monitoring will evolve with these cloud based scenarios. For instance, currently with our on-premise applications we run Microsoft Operations Manager (MOM) and System Center Operations Manager (SCOM) to provide us with some visibility into the health of our applications. If in the future we decide that we want to host a WF workflow in the cloud, what type of tooling will be available to inform us of any issues that may be occurring? This is a scenario that Microsoft is definitely aware of so I will be keeping an eye open on what type of tooling will be available.