Where’s that data?

By Henning Eiben in .Net 0 Comment

ASP.Net applications have a special folder call App_Data, which is specifically designed to hold application-data such as databases. SQL-Server express will place it’s .mdf files here by default.

Because this directory is being protected by the .Net-framework and thus not accessible by clients, it’s a good idea to place other data here as well.

To access this folder a couple of different approaches come to mind. The first idea would be to just access /App_Data/mydata.db hardcoded. While this might work in most scenarios, it will fail if the application is installed in a virtual directory instead of the root.

OK, let’s try something different. How about ~/App_Data/mydata.db? Looks compelling. At runtime the .Net-framework will substitute “~” with the actual base-directory of the application. Unfortunately this is only done for certain elements. So this might not always work. You could of course get the actual path on the server side by using

Server.MapPath("~/App_Data/mydata.db");

Doing some research offers my preferred approach

Path.Combine(AppDomain.CurrentDomain.GetData("DataDirectory").ToString(), "mydata.db");

AppDomain.CurrentDomain.GetData("DataDirectory") will return the path to the App_Data folder wherever that’s actually may be. Nice.

Getting those ASMXs

By Henning Eiben in .Net 0 Comment

Creating a ASMX-page to leverage some service functionality to a client is fairly easy. The nice thing about that is, that you can even consume these services from JavaScript.

But out-of-the-box you can only call those services either via SOAP 1.1, SOAP 1.2 or a POST-request. But what if you want to use a plain-ol’ GET-request? You’ll always get an error-message stating, that GET is not supported – what a bummer.

But working around this problem is quite easy to do. Just open up your code-behind of your ASMX-Service and add

[ScriptMethod(UseHttpGet = true)]

To the method you’re calling. Finally you’ll also have to add the HTTP-GET to the list of "known" protocolls for webservices in the web.config. This is done by adding 

<webServices>
  <protocols>
    <add name="HttpGet"/>
  </protocols>
</webServices>

to the system.web section in the web.config.

Thats all.

Make that personal!

By Henning Eiben in .Net, Programming 0 Comment

Even though I always used to stick with workstion-os to do my developemtn, some of my development-machines are Windows 2003 servers by now. And as a good server I don’t run SQL-Server Express Edition, instead I run a real SQL-Server.

OK – that being said, I recently wanted to create a simple ASP.Net 2.0 application, which would take advantage of the WebPart-Feature of ASP.Net 2.0. But not only placing WebParts in the code on the page, I also wanted to be able to edit settings of those WebParts from within the browser, and do some other cool stuff.

So I turned Personalization=on of my WebPartManager and for this great trust I put into ASP.Net – all I get in return is a lousy error, stating that something went wrong while access the database for my ASP.Net Settings! That is a real bummer! But luckly the page was already giving some hints: maybe I don’t have SQL-Server Express Edition installed on my machine.

After some irritation – since I do have a SQL-Server, but just not the EE (Express Edition) – I finally figured it out (with some great help from a colleague).

So ASP.Net want’s to create a MDF-file in tha App_Data directory of my web-application and then access that newly create database. But this doesn’t seem to work, when you have something else than the EE installed. So you have to tweak ASP.Net a little to get things done.

First of all, create you own custom ASP.Net Settings DB using aspnet_regsql.exe from the current framework directory (e.g. C:\Windows\Microsoft.Net\Framework\v2.0.57[something]). This will bring up a little wizard, which will guide you through the next steps.

Now you have to point your application to the newly created database. A global connectionstring tells the web-application to look for a local database. To change this behavior, you first have to remove the globally set connectionstring, by adding to your web.config a remove element, and then re-adding a new connectionstring, pointing to your custom database. So the web.config section for connectionsstrings could look like this:

<connectionStrings>
<remove name="LocalSqlServer"/>
<add name="LocalSqlServer" connectionString="Data
Source=MyServer;Initial Catalog=aspnetdb;Integrated Security=True;"/>
</connectionStrings>

This should solve any problems.