February 06, 2008

Configuration namespace and reading settings from the Configuration file,app.config,web.config

This one always catches me out.
There are a few different ways to read settings in from a .config file.
The confusion for me occurs when reading from certain sections and from config files other than ones for the currently running application.

The easiest example is reading settings from the currently running application, from within it's own code.
You can access the AppSettings Section
<configuration><appSettings>
<add key="hostname1" value="localhost"/><add key="hostname2" value="othername"/></appSettings></configuration>
using:

NameValueCollection appSettings = ConfigurationManager.AppSettings;
foreach(string key in appSettings.AllKeys)
Console.WriteLine(key + " " + appSettings[key]);

So now you've all the keys in the AppSettings section i.e. "hostname1" and "hostname" and all their values accessed with appSettings[key].
Note: First you must add a reference to 'System.Configuration.dll' to your project and also include the namespace 'using System.Configuration;' You'll also need 'using System.Collections.Specialized;' in order to use the 'NameValueCollection' type.

Similarly but slightly more tricky you can access the settings of another assembly by using the following:

Configuration config = ConfigurationManager.OpenExeConfiguration(@".dll");
KeyValueConfigurationCollection kvpCollection = config.AppSettings.Settings;
foreach (string key in kvpCollection.AllKeys)
Console.WriteLine(key + " " + kvpCollection[key].Value);


You'll see the Settings collection is access in the same way and can be enumerated in the same way but the 'value' of the AppSetting must be accessed using the .Value property?
This is because the former call to AllKeys returns a NamedValueCollection and the latter returns a KeyValueCollection, this means that for one you have access to the values as strings themselves and the other you have access to the type KeyValueConfigurationElement, if you want to get the string value you additionally need to call the Value property!



Open a config for a dll, a dll being referenced by an exe

This reads the config file that's in the location that the exe is referencing the dll from, actually it makes a copy of the dll to the exes bin dir, so you have to add your dll's config file to the exe's bin directory and withing the dll's code add the following

//Only finds copy of the assembly as it's added as a reference to the exe.
System.Reflection.Assembly ass = System.Reflection.Assembly.GetAssembly(typeof(Class1));
System.Reflection.AssemblyName assName = ass.GetName();
string codeBase = assName.CodeBase;
int length = "file:///".Length;//remove the "file:///" from the string
string result = codeBase.Substring(length);
config = ConfigurationManager.OpenExeConfiguration(result);//open the dll's config
kvpCollection = config.AppSettings.Settings;
value = kvpCollection["hostname1"].Value;

February 04, 2008

ASP.NET HttpHandler how to

HttpHandlers are class which extend HttpHandler and which IIS recognises as the classes to use to handle errors etc.
The HttpHandler class is usually stored inside a .ashx file.

You can create your on .ashx and place it in you web app root dir, it will be entered whenever a request comes in from the client.

If you do not want to show your HttpHandler file code in your web app then you can hide it in a dll see details below.

How to hide the .ashx with a HttpHandler

I'll describe here how to create a handler for a file with the extension .ashx, it's coincidental I require a HttpHandler in my web.config in order to alias my .ashx file which is too a HttpHandler.

Note: Before you can compile a HttpHandler into a dll you must remove the directive at the start of the .ashx file e.g. delete this line
<%@ WebHandler Language="C#" Class="MyWebHandler" %>
If you fail to do this your .ashx code will not appear in your dll and you will not be able to register the type MyWebHandler.

One way to hide .ashx files is by a creating a handler for .ashx files.
The Handler is a HttpHandler.
This Handler will handle any calls to to files with the extension .ashx, this could be any extesion (I think), whatever extension you want will be supplied in the Web Applications web.config
e.g. if you created a HttpHandler and you want it to cater for all .ashx files in your Web Application add something like this to your Web Application's web.config :

In IIS 6 Classic Pipeline:
<system.web>
<httpHandlers>
<add verb="*" path="*.ashx"
type="MyWebHandler.Service1,
WebServiceHandler, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=9bae47114a98ed1a"/>
<add verb="*" path="Service5.asmx" type="Service4,
WebServiceHandler, Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=9bae47114a98ed1a"/>

Or if you want to provide handler for a particular ashx file use something like this
<add verb="*" path="Service3.ashx"
type="MyWebServiceHandlerClass,
MyWebServiceHandlerDLL,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=9bae47114a98ed1a"/>


in IIS 7 Integrated Pipeline, the section exists on the <system.webserver> and it has an additional Name attribute:

<system.webServer>
<httpHandlers>
<add name="MyHandler" verb="*" path="*.ashx"
type="MyWebHandler.Service1,
WebServiceHandler, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=9bae47114a98ed1a"/>


<add name="Service4Handler" verb="*" path="Service5.asmx" type="Service4,
WebServiceHandler, Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=9bae47114a98ed1a"/>

<system.webServer>

http://msdn.microsoft.com/en-us/library/46c5ddfy.aspx

Above the strong name is being used to locate the dll, this is because the dll is in the GAC, you do not have to put the dll in the GAC.

The second parameter in the 'type' list above is actually the name of the dll file, the Version, culture, PublicKeyToken, are all the fullname of the dll containing your HttpHandler code i.e. the strong name.

The Handler itself must include your code that was originally in your original file and also Implement the IHttpHandler Interface.
You can compile your HttpHandler into a seperate dll and add it to the GAC with the signature provided in the web.config of vice versa, just make sure that the Strong Name in the DLL is identical to the String name provided in the type in the Web Applications type.

If you choose to put your dll in the web apps bin directory then it can be registered as follows:
<add verb="*" path="Service3.ashx"
type="MyWebServiceHandlerClass,
MyWebServiceHandlerDLL"/>

Note: Only the dll name is required, no extension and no strong name it just needs to exist in the web apps bin directory.

Bug:
There's a small bug in ASP.NET 2.0, if you create a handler and you do not wish to use an assembly to store the HttpHandler code you can simple add the source file to the App_Code directory and just use the type in the web.config without and assembly, well this is how it's supposed to work but actually you have to do one more thing and that is you must create a codebehind file and place the code in there instead and add the details to the Http handlers directive
<%@ WebHandler Language="C#" Class="MyHandler" CodeBehind="MyHandler.ashx.cs" %>
web.config
<add verb="*" path="myfile.something"
type="MyHandler"/>

February 01, 2008

Remoting, Remote Computing

Remote Computing

http://del.icio.us/rss/learnerplates/remoting
http://del.icio.us/search/?fr=del_icio_us&p=remoting&type=user


There are 2 main ways in .NET to invoke a method and/or create an instance of an object on machine other than the one your
1. Webservices
2. .NET Remoting.

1. Webservices allow the client to communicate with the server be emitting an receiving XML, these XML messages are first wrapped on both the client and server side into SOAP envelopes..NET Remoting on the other hand allows a remote client to invoke a method through Proxy classes.

2. .NET Remoting
You can access remote objects in 2 ways, by reference and by value. The first manipulates the actual original object on the server(the objects class must be MarshalByRefObject) , the second a copy of the original object is used which means any changes made will only effect the local copy, copy on the client, of the object (the objects class must be Serializable).

The communication between Server and Client is taken care of for you by a Proxy class. All you have to do is create your remote class, inherit from MarshalByRefObject (or implement the ISerializable interface depending on how your client will be calling your remote object), usually inherit from MarshalByRefObject .
Create a Server class which creates an a remote instance of the remote class and also create a Channel to allow the client to communicate with the remote object.


Here's a very simple Remote class:

public class RemotingClass : MarshalByRefObject
{
public string HelloWorld()
{
return "Hello World!";
}
}
Or better still, in order to hide your actual remote objects implentation, create an interface in a common dll instead (below) of a concrete class (above).
Include the dll as a reference on you Server side and implement the interface with some class. On the Client side also include the dll as a reference and use the interface type to get your remote object instance.
like so:
public interface IRemotingClass
{
string HelloWorld();
}
And change your remote class implementation accordingly
public class RemotingClass : MarshalByRefObject, IRemotingClass
{
public string HelloWorld()
{
return "Hello World!";
}
}
The client code calling this method could be a standalone app (Console App) or a web application (Http Client, running on IIS), the Console App would use TcpChannel the Http Client would use HttpChannel.
Here's a simple Server class (Note if you plan on running your server as a web app or in a web application, place this code inside your Global.asax files Application_Start method and remove the port numbers they're no longer required, if you do this your RemotingClass.cs will need to be in the App_Code dir) :

using System.Runtime.Remoting;
using System.Runtime.Remoting.Services;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
public partial class ServerApp
{
public void main()
{
// Create an instance of a channel
HttpChannel channel = new HttpChannel(1234);//the client must use this port too
ChannelServices.RegisterChannel(channel); // Register as an available service with the name
HelloWorld RemotingConfiguration.RegisterWellKnownServiceType(
typeof (Remoting.RemotingClass),
"RemotingClass.soap", //The name used by client when requesting this remote object, this tells IIS to deal with the request as a Remote request and let the .NET Remoting take care of it.
WellKnownObjectMode.Singleton); // Create an instance of the remote object

}


The Client code then creates an remote instance of the object using a url with the name just given, "RemotingClass.soap", and a channel to the same object with the same port 1234.


class ClientStartup
{
static void Main(string[] args)
{
//Send out messages on any port port
HttpChannel httpChannel = new HttpChannel();
//Requests will be sent through Http, which are SOAP messages.
ChannelServices.RegisterChannel(httpChannel);
//Get a reference to the remote object using the url
//Note that the same port number is used as on the Server, 1234
IRemotingClass remoteClass = (IRemotingClass)Activator.GetObject(
typeof(IRemotingClass),
"http://localhost:1234/RemotingClass.soap");

string result = remotingClass.HelloWorld();
Console.WriteLine("The Customer has been gotten on the client remotely with the age : " + result);
}
}

Hosting the Remote objects on IIS

When your objects live in a Web Application i.e. in IIS, you can use IIS's power to do some of the work for you, like security.

The above example can be run on IIS by simply placing a version of the code we had in the Server's main method into our web applications Global.asax files Application_Start method. This ensures that the remote service is initiallized only once i.e. when the web app starts.

The code will have to change slightly

HelloWorld RemotingConfiguration.RegisterWellKnownServiceType( typeof (Remoting.RemotingClass), "RemotingClass.soap", WellKnownObjectMode.Singleton);

As you can see the code has been simplified, there's no HttpChannel or Port number, because this remote object will not be referenced by the client using a Url instead of a machine and Port number i.e. using http://localhost//RemotingClass.soap

like so

HttpChannel httpChannel = new HttpChannel();
ChannelServices.RegisterChannel(httpChannel);
IRemotingClass remoteClass = (IRemotingClass)Activator.GetObject( typeof(IRemotingClass), http://localhost///RemotingClass.soap");
string result = remotingClass.HelloWorld();
Console.WriteLine("The Customer has been gotten on the client remotely with the age : " + result);

SoapSuds.exe

In the above examples we've used an interface on both Server and Client sides, this interface hid our true implementation from the Client, all the Client is aware of is the interface. This works fine but there is another way to implement this and that is with a representation of our remote class that is created from the WSDL of our remote object. The WSDL of our remote object can be accessed using the Url to our remote object followed by ?WSDL, (remember this in SOAP and webservices).
The SoapSuds.exe is an app found in the Visual Studio SDK e.g. C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\soapsuds.exe.
You pass soapsuds.exe your WSDL output and it generates a class representation of your remote object, this representation will be very similar to your real object on the Server side with additional SOAP attributes.
e.g.
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0>soapsuds -url:http://localhost//RemotingClass.soap?wsdl -od:C:\temp

This class can now be used by the Client instead of the Interface IRemotingClass.

But what is the usefulness of this?
One use of this is that is provides the concrete class instead of the interface which is required when you are using Configurable Settings on your Server side.
Configurable settings allow you to dynamically change the remote object name and port at runtime using you config file, one issue with this however is that the Client side requires the concrete implentation in order to reference it.
e.g.
<configuration><
system.runtime.remoting><
application><
service><wellknown mode="Singleton" type="RemotingClass, RemotingClassAssemblyName"objectUri="RemotingClass.rem"/>
</service>
<channels>
<channel name="MyChannel" priority="100" ref="http"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>