Bill,

while we will look into what might be causing this issue in Cassini, could you please try this: run the application under IIS from IIS root folder, so that your application would be accessible via http://localhost/. See if that exhibits behavior different from Cassini. Some applications break when moved from virtual folder to web server root because ASP.NET Request.ApplicationPath property returns "/" for root application, and "/applicationfolder" - without trailing '/' for applications in virtual folders. If moving application to IIS root still shows different behavior from Cassini, please let us know how those incorrect URL get formed. Code snippets would be helpful.

Best regards,
UltiDev team.

Bill,
we'll do our best to find and fix the problem if it ends up being a problem with Cassini. DNN is a pretty complex animal as far as we can tell, so some work to port DNN applications to Cassini may be required. In our case, to test DNN with Cassini we ran DNN Install package on Cassini. I think we had to do some minor tweaks, but given that it was our first-ever exposure to DNN, it went surprisingly smoothly. Another thing worth mentioning is that Ultidev Cassini executable can be used for your ASP.NET application debugging. If something is not right, debugging with Cassini will take you closer to the source of the problem, especially if problem is related to differences between Cassini and IIS. Please check the debugging section of Cassini Dev Guide to see if that will help you.

Regards,
UltiDev Team.

Hello, Bill.


Actually, those were not so much tweaks, but more of having trouble following DNN installation instructions with creating and editing its .Config file and with SQL database, not with the web server. DB had to be manually created, and SQL users/logins had to be created and mapped. After that we just registered DNN under Cassini and ran installation. It all is running on XP Pro. The only hitch was that installation has not completed the first time we ran it. It seemingly timed out. We unzipped DNN Install again, created config again and ran it. This time it ran without a hitch.


Thrilled to hear that! Hope you have fun working with it.


Bill, MS gives VB.NET Express edition away for free. You can download it here.

Best regards,
UltiDev Team.

I see it's been awhile since the last entry in this topic, but I have the same type problem. Early in the DNN 3.2.2 installation, it's looking for a database version which it won't find in the database because DNN hasn't even had a chance to create its tables yet. So it creates a path from some mapped path value (using a virtual path I guess), but it also is missing a trailing '\' so that the file name gets glommed onto the path name, something like \Providers\DataProviders\SqlDataProvider00.00.00.SqlDataProvider, which name is created at line 136 of file ~\Providers\DataProviders\SqlDataProvider\SqlDataProvider.vb. The file is called 00.00.00.SqlDataProvider, the path it got from a translation of a path it gets from HttpContext.Current.Server.MapPath( the-path-from-the-config-file ) (lines 121, 126). The path is specified in the config file as providerPath="~\Providers\DataProviders\SqlDataProvider\", so we know it already has the trailing '\' in it. So something in this particular HttpContext object is mapping the path incorrectly (I can only presume for now that UltiDev Cassini provides this object ??).

Your point about well-formed paths is quite correct ... but DNN code is what it is. I am using UltiDev Cassini 1.1, on .NET 1.1, on Windows XP Home (without IIS, thus my desire to use your cool product), with DotNetNuke 3.2.2.

Alright, we determined that MapPath() in Cassini 1.1 is not working exactly as in IIS, while Cassini 2.0 works just like IIS. We traced the inconsistency to the original Cassini code distributed by MS. We fixed the issue and it will be available in the next build of Cassini 1.1. Hopefully this will take care of the DNN 3.x.x issues.

Regards,
UltiDev Team.

Hi!
We are planning the release within next 4 to 6 weeks, but users who commit to test the product for a few hours and provide feedback can get the current build with all the current fixes in place within a week or so. Contact us by email if you are interested.

All the best,
UltiDev Team.

Hi there!

"aspnet_client" folder is a cheat to make certain features available to all applications running under IIS specifically. The workaround for applications under Cassini would be copying the aspnet_client folder with all its contents to folder containing your application. For example if your application's main page is c:\webapps\myapp\WebForm1.aspx, then you may need to copy aspnet_client from "c:\inetpub\wwwroot" to "c:\webapps\myapp".

All the best,
UltiDev Team.

Hi!

Since Visual Studio's web server works, it means "aspnet_client" folder is physically present somewhere on your hard drive. Once you locate it, please copy it over to the folder containing your web applicaiton.

Regards,
UltiDev Team.

Nancy, thank you very much for sharing the solution!

Best regards,
UltiDev Team.