Thank you for the Cassini desktop adapter, you did a very nice job! We have a windows form based application that uses webservices for server communication. We have decided it would be benificial to produce a demo version of our system that runs completly from the users machine. The basic flow of the demo app is

Application starts
Application starts Cassini via the desktop adapter
Application re-sets the webservice URL for the local machine using the port returned from the adapter
Application uses webservices
User closes application and we shut everything down

the important part of all that is we do not need or want any webbrowser to be visible as part of the process. We implemented our demo version using the desktop adapter, cassini and a pre-compiled version of our webservice site. Launched the application and it worked perfectly on a Vista machine - even on the clean Vista machines we use for testing it worked. Expecting it to work on XP almost seemed like a "given" until we tried it. On XP, Cassini launches via the adapter and we get the port, but when the webservice is called, Cassini seems to hang and finally after a long time gives a timeout. To verify the site did not have a problem, we launched Cassini manually, the same way the adapter does, and the website, plus webservices all worked correctly. The only difference in our manual launching and the adapter launching is we use one of the methods from the adapter that appends the "nobrowser" flag at the end of the arguments. We wrote a small test application that launches the site diferent ways and calls a webservice hosted in the site. An we found consistely if the "nobrowser" flag is appended we get the results described above, if we call a method in the adapter that does not append "nobrowser", and thus a webbrowser is launched, then the webservice and page loaded in the browser and everything works correctly.

We have tried updating Cassini to the latest version, but the problem still persists for XP. As long as "nobrowser" is not an argument to launch Cassini, it works on XP, otherwise Cassini hangs when a request arrives. Loading the site does not seem to be the problem, since we get a port number back and can see cassini running- only when a request arrives from our app, or from a manually launched web brower does it hang.

Has anyone else seen this behavior on XP?
TIA

Hi Ryan,

Thanks for the quick response. I ran a test using your info on both XP and Vista using the same site code from previous tests. It worked perfectly on both XP and Vista. Thank you for solving my problem. KUDOS to you!

Hi Ryan,

I have run into another issue in relation to this post. In my original problem description when I mentioned the application, it is an add-in for Excel, thus a DLL( implemented via VSTO in C# ). When I connected Cassini to the add-in via adding a reference as described above, I get the error

System.SystemException was unhandled
Message="Failed to create AppDomain."
Source="System.Web"
StackTrace:
at System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironment(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironmentAndReportErrors(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ApplicationManager.GetAppDomainWithHostingEnvironment(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ApplicationManager.CreateObjectInternal(String appId, Type type, IApplicationHost appHost, Boolean failIfExists, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ApplicationManager.CreateObject(String appId, Type type, String virtualPath, String physicalPath, Boolean failIfExists, Boolean throwOnError)
at System.Web.Hosting.ApplicationManager.CreateObject(String appId, Type type, String virtualPath, String physicalPath, Boolean failIfExists)
at Cassini.Server.GetHost()
at Cassini.Server.OnSocketAccept(Object acceptedSocket)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
InnerException: System.NullReferenceException
Message="Object reference not set to an instance of an object."
Source="System.Web"
StackTrace:
at System.Web.Hosting.ApplicationManager.GetDefaultDomainIdentity()
at System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironment(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
InnerException:

So to make sure I had not created a new error somehow, I took the test code I used in my winform application which works correctly under XP & Vista and moved it into a new empty VSTO add-in and ran it under Excel and I get the same app domain error as above. Thus the same code works in an winform exe, but not in the Excel addin DLL. I have looked for info in the forum on using Cassini from a DLL but did not find anything that looked promising. Is there a requiment it must be hosted via WinForms application???? The DLL created by VSTO is simliar to a class libary but not the same as a class libary.

Hi, nemo.

There is apparently a limitation on creating web hosting app domains from inside a CLR app domain hosted by Excel process. We are not sure what that limitation is - probably it's related to parent domain's security settings - and unfortunately MSDN is mum on the topic. We could suggest attempting creation of a separate, "normal" (non-Excel) process that will instantiate CassiniAdapter and host your application.

Please post, if possible, the content of the InnerException that is cut off in your original posting.

Best regards,
UltiDev Team.

Hi there!

Thank you for the additional information. Looks like the InnetException was not not missing - it's just null, so your original posting contained all the information there is. We still suspect it has to do with the security context around VSTO app domain, so our best guess for the workaround remains hosting the ASP.NET part of your app in a separate process launched from outside of Excel.

Best regarrds,
UltiDev Team.