|
I've never used MySQL so I don't know if it will work. Does MySQL support the concept of Triggers? If so, it may be possible to write one that will notify the client somehow.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
"On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question."
--Charles Babbage (1791-1871)
|
|
|
|
|
Hi All,
Where Can i Download link for ms-avalon library??
I can't find any links from microsoft.com
There is informations only links...
please help me...if you have
i wanna to test XAML programs on longhorn build 4051
|
|
|
|
|
|
|
Do you know how to read/write from/to registry oc a Pocket PC?
Do we need any other library to do this?
Best regards
|
|
|
|
|
|
Hi,
if i just buy a VC++.Net but not the whole Visual Studio.Net
package, can I still use it to develop software for Pocket PC 2003/Smartphone by using the compact framework extension ?
and can I develop software on PocketPC/Smartphone by using
C# ?
Thanks
|
|
|
|
|
"There is no official support for Visual C++ development for .NET applications using the Compact Frameworks. However, applications that you build using the /clr:safe option and that use only CLR and BCL features support by the Compact Frameworks will be able to run on CE devices." - MSDN.
|
|
|
|
|
Hi all,
I have three questions,
1. What are the limitation of C# compared to C++.net ?
2. will MFC in VC++ be obsolete in future ?
3. Do we need to obsfucate the code in C++.net as in C# for
protecting the reverse engineering of software code ?
Thanks
|
|
|
|
|
pyhtang1 wrote:
1. What are the limitation of C# compared to C++.net ?
C#'s not C++, however both are compiled to MSIL which is JIT compiled to native code (See Compiling to MSIL.) C++, however enables you to use easily use the full power of native code, pointers, etc. within managed code. However, C# is also powerful in that it can leverage native code through calls to Unmanaged Code and also can access pointers with some caveats (see C# Language Specification Appendix A Unsafe code).) C++ also allows for templates and the STL for the "behind the scenes" code. C# won't have anything similar until Generics are officially released as part of the language specification.
pyhtang1 wrote:
2. will MFC in VC++ be obsolete in future ?
No. MFC is quite mature [and so is ATL!] for robust, straight Win32 applications, and will be part of VC++ for the forseeable future.
pyhtang1 wrote:
3. Do we need to obsfucate the code in C++.net as in C# for
protecting the reverse engineering of software code ?
For native C/C++, you can just strip out the symbols. But for C++.NET, since it is compiled to MSIL (as are any languages compiled to MSIL such as C#, VB.NET, COBOL.NET, et al.) you must obfuscate if you wish to hinder reverse-engineering.
|
|
|
|
|
Hello
I have a .Net Dll
MagicLibrary.dll
who can say how to use a badly named namespace
Crownwood.Magic.Controls
which is badly named
Crownwo╗$d.Magic.Library
I think it is locked but i have a software that uses this
component without anymore files in runtime
but i don't know anything about design time.
Is there anybody who can use or disassemble this library
for me?
yzs
|
|
|
|
|
The magic library used to be freely usable.
Now it is not. The runtime can be used by applications which were built using the licensed version, but the design time is locked to the end user without a license.
|
|
|
|
|
FYI: The license disallows dissasembly (it's illegal,) like in most other commercial software licenses.
|
|
|
|
|
I was looking through the docs for what type of sockets I can create with the System.Net.Sockets.Socket class and I saw "RDM" - Reliable Data Messaging. To me this seems like quite a nice swap-in alternative to UDP in some cases [when speed isnt terribly important, but there's no need to create a connection then destroy it like TCP would require]
I tried to create it with the address family InterNetwork [IP v4.. normal internet] and Undefined protocol-type... since there's nothing there that looks like it would be RDM.
When it tried to create the socket, it threw an exception that the address family doesnt support RDM.
Now... for one I'd like to have RDM for Internetwork..... but in any case.. does anyone know where I can find any info about the different socket-type/protocol combinations with their supporting address families.
Thanks.
|
|
|
|
|
I'd like to set a "Special Build" property/attribute in the Assembly of my project (or in a resource file) -- something that gets compiled in.
I've looked around the net for this and it's really not clear to me.
I'm using Visual Studio.NET 1.0 and my App is standard C#. I've actually got two flavors of the app (one command line and one GUI) and I need to set the "Special Build" string differently for each app (E.g., I don't want to do it in code, I just want to set the values differently in either resource files or in the AssemblyInfo.cs file).
Thanks for any tips!
|
|
|
|
|
I think you need to write an .rc file, compile it with rc.exe, then use the /win32res switch to compile it into the assembly.
Not tested, no warranty, usual disclaimers apply...
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I am running .NET remoting server hosted in IIS, the function is collecting all the logged in user account, but after it got the first one, I had "ChannelServices" is out of scope exception. Does any one know what caused it?
|
|
|
|
|
Greetings CodeProject Gurus. I have an interesting problem that I hope you can advise me on.
I need to design an assembly thatacts as a hardware interface for something. The assembly will attach to a single Comm port (I'm using JH.CommBase for that). The assembly must expose three different interfaces. Each interface may be accessed by a different application, through native .NET or perhaps via COM Interop at run-time.
So here is my problem: when the three different applications launch and create instances of the interfaces, three seperate copies of my assembly get loaded. Each instance tries to open the single Comm port and naturally only two of them succeed.
Clearly, I have an architectural design issue here. I wonder how you guys would deal with this issue? Is there a way to design an assembly that implements the Singleton pattern, but _systemwide_ not just _application wide_? Or maybe a radically different solution?
Regards,
Tim.
|
|
|
|
|
Could you design your system so that the access to the COM port was through a Windows Service. They you could have your three applications safely communicate with one windows service which, in-turn, commuicates with the one COM port.
Does this help?
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
|
|
|
|
|
This is an option I have considered, but I'm not sure how an application communicates with a service. I guess I could RTFM  Not sure how I would support W98 systems though.
Another idea I have considered is use of MSMQ, or maybe .NET Remoting. Both of these techniques might have other beneficial side-effects for my projects. I guess I was just hoping there is someone out there who has been in a similar situation and could tell me how they solved it.
Thanks for the suggestion,
Regards,
Tim
|
|
|
|
|
Yes, just create a service and expose an interface using .net remoting, that interface should not be the singleton.
i.e. you can create it as WellKnownObjectMode.Singleton but this will backfire. It is better to make the singleton a seperate class from the remoting object:
The reason for this is if your object has not been used for a long time then remoting may create a new instance, and since this is done by serialization you can end up with multiple instances!
alternativly see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimeserializationiserializableclasstopic.asp[^] for info on how to handle this issue.
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
Sounds similar to the multiple instances problem. If you are writing in C++, you can have a shared data segment with the necessary comm code there.
At least, I think that should work.
http://www.codeguru.com/Cpp/W-P/system/misc/article.php/c5663/
|
|
|
|
|
Scenario:
There are 2 applications: first is a server which creates a remote object and second is a client which receives remote object (as a proxy object).
My problem is that I want to fire an event (or call a method...) for Remote Object (RO) from the server, but on the same object.
How can I do that?
|
|
|
|
|
can you restate this:
"My problem is that I want to fire an event (or call a method...) for Remote Object (RO) from the server, but on the same object." i'm not sure what you mean...
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
it is a part of that book's chapter :
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
Chapter 6
299
300 Chapter 6 • Remoting
Introduction
Ever since the early days of Windows programming, there has been a gradual
improvement in operating system stability. Much of this is due to the separation
of applications into distinct processes so that each has its own area of memory.
Developers have had to use many tricks to get these applications to communicate
with each other. Some of these methods included using the system clipboard,
sending windows messages, using the Visual Basic (VB) SendKeys function or similar,
transferring “message” files, or declaring an area of shared memory. Each of
these methods had pros and cons and were generally “hacks” around the separation
of processes.When Microsoft’s Component Object Model (COM) arrived,
the situation vastly improved, and such tricks were no longer needed, but COM
did introduce a number of issues with versioning, registration, and administration
that a generation of Windows developers has had to deal with. Now with the
.NET platform, you get cross-application communication built-in, which provides
you with an amazing amount of flexibility and control as to how you want
your applications to communicate with each other.
Every application on the .NET platform exists in its own unique Application
Domain.And every Application Domain is able to expose objects to the outside
world from any type of application—from simple console applications to Windows
Forms and Internet Information Server (IIS)–hosted applications.To enable applications
running in one Application Domain to communicate with other applications
in another Application Domain, you use remoting.Or you could say remoting
allows you to call methods and pass objects across Application Domains.
The Remoting API on the .NET platform takes a different approach than the
other application programming interfaces (APIs), such as Distributed COM
(DCOM) and Remote Method Invocation (RMI) for communication and message
format. Rather than relying on a proprietary message and protocol, the
Remoting API uses well-established standards such as Simple Object Access
Protocol (SOAP) for messaging and Hypertext Transfer Protocol/Transmission
Control Protocol (HTTP/TCP) protocols for communication.This allows applications
to communicate just as easily across the Internet as they do within the
enterprise.
To understand how remoting works, imagine that you need to create your
own method of cross-application communication. Imagine that you have an
object that needs to accept calls from client applications across HTTP. First, you’d
need to define your object’s location as a URL of some kind.Then you would
need to choose a port that the object should listen to.You would also need some
www.syngress.com
www.syngress.com
way of publishing the interface of your object so that clients would know what
methods are available to call, and you would need a method of describing the
interface and handling the messaging between objects.The creators of the .NET
Framework have done just that and have exposed the remoting functionality as a
powerful way for programmers to start getting their applications to communicate.
This chapter introduces the remoting framework and provides many examples
from real-world scenarios that occur during development. First, we get an
overview of how remoting works and look at the variety of choices available to
the developer as to how remoting is configured.
In the second part of the chapter, we produce a simple remoting example that
is gradually extended to use a range of remoting services.We also take a look at
how to deal with issues that developers face during the development lifecycle in
regard to deployment, debugging, administration, documentation, and versioning
while using the remoting framework.
Introducing Remoting
Remoting provides you with a number of choices as to the method and configuration
of communication used. Configuration areas are the choice of channel, type
of hosting application, the activation model, the configuration method, and the
method of exposing server metadata to the client application.
The channel is the means of communication used by an application to call to
a remote object; the selection is between HTTP and TCP (SMTP doesn’t appear
to be ready in Beta 2).The HTTP channel is mostly used for Internet communication
where firewalls need to be negotiated.The TCP channel has a performance
gain by using direct socket connections over an arbitrary port selected by
the developer. Both channels use SOAP for communication; the TCP channel
defaults to use a faster (but proprietary) binary representation of the SOAP message,
whereas the HTTP channel defaults to use the XML standard.The TCP
channel can also use the normal XML-formatted SOAP messaging format.
The selection of the hosting application for the remote object is the next
choice.A hosting application must be configured to listen on a channel and
create the requested object in its own AppDomain when required. In Visual Basic
6, developers often used IIS or COM+ services to host remote objects—the mysterious
dllhost.exe that you may see running in your Windows 2000 Task
Manager is the hosting application used by COM+.With the .NET Framework,
you can still use these hosting services, but you can gain more control by writing
your own hosting applications.When creating your own hosting application, as
Remoting • Chapter 6 301
302 Chapter 6 • Remoting
we do in the first example, you may choose from a Console application,
Windows Service, or Windows Forms application.
Choice number three is the activation model for the remote object. SingleCall
objects are stateless in that they handle only single calls from clients and do not
hold state between calls. After the call is handled, the object is discarded. Singleton
objects can be shared between multiple clients.They are often used when the
resources needed to initialize the object are large and the object’s state needs to
be preserved between method calls.You need to remember that Singleton objects
do have a default lifetime and may be recycled—we’ll see later how developers
can control the object’s lifetime to suit their needs. Client Activated Objects
(CAOs) allows a client application to create a remote instance of the object for
exclusive use and to preserve state between remote method calls.
Choice number four is the method of configuring the remote server.The
host application can programmatically configure itself on startup or a configuration
file can be used. Of course, using an external file to hold remoting configuration
data enables changes to be made without a recompile of the source code.
The configuration information contains the channel, port, activation model, type
name, and assembly name of the object. A Uniform Resource Identifier (URI),
which clients use to identify the object, is also specified.
The final choice is how the client obtains the remote object’s metadata. Again
comparing with Visual Basic 6, a server object’s interface definition had to be on
the client, either as a type library or an exported MTS package, to enable the
client VB code to make the call over DCOM.With remoting, the situation is
similar but improved by the .NET Framework’s use of metadata.The first method
is to set a reference to the remote object’s DLL in the client project so that the
compiler can extract the metadata.The second method, but only if using the
HTTP channel, is to use the soapsuds.exe utility to generate a “proxy” class from
the remote object’s URI.This proxy class can then be included in the client project
and used as if it is a local .NET type. Internally, the proxy class will route the
call to the remote object.
Remoting Architecture
An end-to-end picture of remoting is as follows.The host application is loaded
and registers a channel and port on which to listen for incoming calls.The con-
figuration file, if any, is read and an object’s remoting information is loaded—the
host application can now map a URI to the physical assembly and instantiate the
object when required.The client application also registers the same channel and
then attempts to create a new instance of the remote class.The remoting system
www.syngress.com
Remoting • Chapter 6 303
handles the request for a new instance by providing a proxy object in place of the
actual object on the server.The actual object is either created immediately for
CAOs or on the first method call for Singleton/Singlecall objects—the remoting
framework takes care of this for you automatically.When the client calls a
method on the proxy object, the information is sent across the channel to the
remote object.The remoting system will then pass back the results of the method
across the channel in the same manner.
Creating a Simple
Remoting Client Server
We’ll now create a simple client server application to demonstrate the usage of
the remoting framework.The code for the server side is located in the ListServer
directory of the CD—double-click on the solution file ListServer.sln so that you
load both the server and the hosting application together. First, we’ll create the
remote class named CompanyLists that contains the functionality.All of the following
code is on the CD.
NOTE
The code in this chapter uses localhost as the target server—this will selfreference
your local computer so that you may use both the client and
server code on the same PC. If you wish to place the server-side code on
a remote server, you will need to replace localhost with the correct server
name.
Creating the Remote Server Object
The remote server object contains all the server-side functionality for our
application:
1. Create a new Class Library application in Visual Studio named
ListServer.
2. Right-click the default Class1.cs module in the Solution Explorer and
choose Delete.
3. Right-click the ListServer project in the Solution Explorer, select Add
| Add Class, and name your new class CompanyLists.cs.
www.syngress.com
304 Chapter 6 • Remoting
4. Modify the class declaration to inherit from MarshalByRefObject so that a
reference to the object can be passed remotely:
public class CompanyLists: MarshalByRefObject
{
}
5. Add a private variable to the CompanyList class that contains an array of
strings:
private String[] Countries = {"Spain","France","Italy"};
6. Add a public method to CompanyList that returns the array of strings
defined in the preceding step.The complete class should appear as:
public class CompanyLists: MarshalByRefObject
{
private String[] Countries = {"Spain","France","Italy"};
public String[] getCountryList()
{
return Countries;
}
}
The CompanyList class can now be loaded by a hosting application for
remoting. If you already have classes that you’d like to make remoting aware of,
it’s as simple as inheriting from MarshalByRefObject and then recompiling.
NOTE
If your class must receive and send objects during method calls, you
will need to use the <serializable> custom attribute to pass these
objects by value or inherit from MarshalByRefObject to pass by reference.
An example of this is shown later. If your class already inherits from
another class, you’ll need to make the parent class inherit from
MarshalByRefObject because multiple inheritance is not allowed in C#.
www.syngress.com
Remoting • Chapter 6 305
Creating the Hosting Application
Now we create the hosting application.This will be a console application initially,
but in the real world, this would probably be a Windows Service application:
1. From the Visual Studio menu, choose File | Add Project | New
Project. Select Console Application and name the new project
ListHost.
2. Rename the default Class1.cs file to CompanyListHost.cs.
3. Add a reference to the System.Runtime.Remoting namespace and the
ListServer project.
4. Add the following using statements at the top of the code window to
reference the relevant namespaces:
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtim.Remoting.Channels.Http;
5. Add the following code to the Main method.This code creates
an HttpChannel object that uses port 8080.The RegisterChannel
method is then used to register the channel, after which the
RegisterWellKnownServiceType method is called to register the class with
the remoting framework.The RegisterWellKnownServiceType method contains
three parameters that specify the type of the remoting class, the
URI, and the object activation mode. After this method has been called,
your class is then ready to accept requests from client applications.
static void Main(string[] args)
{
HttpChannel myChannel = new HttpChannel (8080);
ChannelServices.RegisterChannel(myChannel);
RemotingConfiguration.RegisterWellKnownServiceType
(typeof(ListServer.CompanyLists),
"CompanyLists", WellKnownObjectMode.Singleton);
}
www.syngress.com
306 Chapter 6 • Remoting
6. Build the console application to create the ListHost.exe console
application.
The CompanyList class can now accept calls from remote clients.You’ll notice
that we have chosen port 8080 to listen to for client requests.The choice of port
is rather arbitary, although port 80 should be used to be firewall friendly.You
need to remember that a port can only be registered once per machine.To see
what happens when an attempt is made to register the same port twice, perform
the following experiment:
1. In Windows Explorer, find and run the host application ListHost.exe.
2. While the console application is running, run the same host application
from within the Visual Studio IDE.You may need to right-click the
ListHost project in the Solution Explorer and select Set as StartUp
Project to enable the IDE to do this.
3. Figure 6.1 shows the exception that occurs when the same port is
reused.
Creating the Client Application
The client application will be a standard Windows Application with a main form,
but it could also be any other type of .NET application.The source for this project
is located under the ListClient directory of the CD:
1. From the Visual Studio menu choose File | New | Project. Select
Windows Application, and name the new project ListClient.
2. Rename the Form1.cs file to ListClient.cs.
3. Add a reference to the System.Runtime.Remoting namespace and also to
the ListServer.dll.
4. Add the following using statements at the top of the ListClient.cs code
window to reference the relevant namespaces:
www.syngress.com
Figure 6.1 The Exception Generated after an Attempt to Reuse a Port
Remoting • Chapter 6 307
using ListServer;
using System.Runtime.Remoting;
using System.Runtime.Remoting Channels;
using System.Runtime.Remoting.Channels.Http;
5. Modify the code in the Form1 constructor to appear as follows so that a
new HttpChannel object is created and registered on application startup:
public Form1()
{
InitializeComponent();
HttpChannel c = new HttpChannel();
ChannelServices.RegisterChannel(c);
}
6. Add a button and a textbox to the form. In the button’s click event, add
the following code.This code will create a reference to the remote
object by using the Activator.GetObject method.Three parameters are
used by this method to specify the type of the remote class, its URI, and
the creation mode.The list of countries is then retrieved and used to
populate the form’s ListBox control:
private void button1_Click(object sender, System.EventArgs e)
{
CompanyLists cLst = (CompanyLists)Activator.GetObject(typeof(
CompanyLists),"http://localhost:8080/CompanyLists",
WellKnownObjectMode.Singleton);
listBox1.DataSource = cLst.getCountryList();
}
7. Run the host application ListHost.exe and leave the console window
open. Figure 6.2 shows the host application.
www.syngress.com
308 Chapter 6 • Remoting
8. Run the ListClient application. Click the button to retrieve the list
country list from your server object. In Figure 6.3, you can see that the
county list has been successfully obtained from the remote object.
Understanding the Remoting Code
The host application simply needs to register a channel and port
using RegisterChannel and to register the remoting object using
RegisterWellKnownServiceType.The RegisterWellKnownServiceType method
takes three parameters—the type of the object, the object’s URI as defined
by the developer, and the creation mode.The first parameter provides the link
between the hosting application and the remoting object—this is why having a
reference to your class library’s DLL is necessary. Developers that have used previous
versions of Visual Basic may notice that we cannot magically determine the
location of a DLL using CreateObject.We must explicitly tell the compiler the
DLL’s location.This is actually a major benefit of the .NET Framework because
we no longer must trust that the Registry has accurate information to instantiate
an object.
Another important point is that an object does not “own” a channel.You are
free to register as many channels and objects in the hosting application as you
like. Communication on the server side is multithreaded, so there is no need to
worry about a request blocking a channel while processing is done.You may also
want to use one channel for Internet clients and another for intranet clients and
force this policy by screening ports on your proxy server.
www.syngress.com
Figure 6.2 The Server Application Waiting for Clients
Figure 6.3 The Client Application
Remoting • Chapter 6 309
The client application must also register a channel, but in this case the port
does not need to be specified.This may seem strange at first—doesn’t the client
need to know which port to communicate with? The confusion lies in the
double life of the HttpChannel class. Creating a HttpChannel object actually creates
a ClientChannel and a ServerChannel object.The ClientChannel object does
not need a port number because it can communicate with any port specified in
the URL.You could replace HttpChannel with ClientChannel in the client code
and everything would still work fine.The ServerChannel object is given to us for
free by the remoting framework so that the server object can call back to the
client if needed. By specifying a port when creating a HttpChannel, we are
allowing our client app to “listen” on this port, but it has no influence on what
port our app may talk to. Also, if you are a lazy programmer, you can actually
forget about registering a channel altogether.The remoting framework will create
one for you the first time you attempt to reference a remote object.Try commenting
out the two lines of code that create and register a channel on the client
(shown in Step 5 in the previous section) and then rerun the application.
The client application also needs a reference to ListServer.dll but for a different
reason than the hosting application has a reference.The hosting application
needs the reference so that it can create the remoting object to handle incoming
requests.The client application needs the reference only so that it can access the
DLL’s metadata. As you will see soon, the SoapSuds.exe utility removes the need
to reference the DLL by extracting the metadata and providing it to the client in
the form of a proxy class.
To obtain a reference to the remote object, Activator.GetObject is used.This
method takes two parameters—the type of the object and the remote object’s
URI.The reference returned by GetObject is actually a reference to a proxy
object that routes messages to the remote server.The remote object is not created
until the client makes the first method call.This explains why the first time the
button is clicked in our example application that there is a delay—the remoting
framework is instantiating the remote object. And for those developers that
deleted the code to register the channel, there will be a slightly longer delay
while the framework sets up a default channel for you to use.
Note that if you are using the HTTP channel then the host application can
be tested by typing the remote object’s URI into a browser.Try typing in
http://localhost:8080/CompanyLists?wsdl into Internet Explorer. As long as
the host application is running and configured correctly, you’ll see the SOAP definition
of the remote class as it appears in Figure 6.4.
www.syngress.com
310 Chapter 6 • Remoting
Improving the Sample Application
Although the sample application is a good start and has shown how to execute
calls to a remote object, some areas need improving in order to become a more
real-world application.We introduce these improvements by adding to the sample
code one step at a time.
Adding Event Logging and Error Handling
A good coding standard would be to always have a hosting application write to
the event log information regarding startup success or failure, the application
name, server port number, and any other useful data.We now add event logging
and error handling to the sample hosting application.This updated code is in the
CompanyListHost2.cs file on the CD.The complete code for the host is shown
in Figure 6.5.
Figure 6.5 Adding Event Logging and Error Handling to the Hosting
Application
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using System.Diagnostics;
namespace ListHost
{
public class CompanyListHost
www.syngress.com
Figure 6.4 The SOAP Definition of the Remoting Class
Continued
Remoting • Chapter 6 311
{
EventLog myLog = new EventLog();
myLog.Source = "ListHost";
bool failed = false;
try
{
HttpServerChannel myChannel = new HttpServerChannel (8080);
ChannelServices.RegisterChannel(myChannel);
myLog.WriteEntry("Registered HTTPChannel(8080)");
}
catch (Exception e)
{
myLog.WriteEntry("Failed to register HTTPChannel(8080) " +
e.Message,System.Diagnostics.EventLogEntryType.Error);
failed = true;
}
try
{
RemotingConfiguration.RegisterWellKnownServiceType(typeof(
ListServer.CompanyLists), "CompanyLists",
WellKnownObjectMode.Singleton);
myLog.WriteEntry("Registered ListServer.CompanyLists as
Singleton");
}
catch (Exception e)
{
myLog.WriteEntry("Failed to register ListServer.CompanyLists
" + e.Message);
www.syngress.com
Figure 6.5 Continued
Continued
312 Chapter 6 • Remoting
failed = true;
}
if (failed)
{
System.Console.WriteLine("Errors at startup –
see Event Log.");
}
System.Console.WriteLine("Press [Enter] to exit...");
System.Console.ReadLine();
}
}
The code that writes messages to the event log is quite straightforward.The
WriteEntry method of the EventLog object is used to write error messages from
within the catch blocks. Error handling has been added to trap exceptions caused
while setting up the remoting configuration.
Using the soapsuds Tool
The need for every client application to have a reference to the remote assembly
may be inconvenient for some third-party services.You use the soapsuds.exe tool
to create a proxy object from the remote assembly’s metadata so that a reference
to the assembly is not needed.We now modify the sample application to use this
proxy object by following the next few steps (The updated ListClient code is
located in the ListClient2.cs file on the CD):
1. Open the ListClient project in Visual Studio.
2. From the command prompt, type soapsuds –url:http://
localhost:8080/CompanyLists?wsdl –gc.This creates a proxy
class named ListServer.cs.
3. Copy the ListServer.cs file to your source code directory.
4. Remove the project’s reference to ListServer from the Solution Explorer
window.
www.syngress.com
Figure 6.5 Continued
Remoting • Chapter 6 313
5. Right-click the ListClient project in the Solution Explorer window.
Select Add | Existing Item and choose the ListServer.cs file to add
it to your project.
6. Modify the button1_click method so that the code is as follows:
private void button1_Click(object sender, System.EventArgs e)
{
CompanyLists cLst = new ListServer.CompanyLists();
listBox1.DataSource = cLst.getCountryList();
}
7. Build the application.
Notice that the ListServer.cs file has taken the place of the reference to the
remote assembly. Inspection of the ListServer.cs code reveals that this class is
acting as a proxy by routing the remoting calls to the remote object’s URI.This
allows us to do away with the use of Activator.GetObject to obtain a remote reference—
we can now program against ListServer as if it was a local class.
NOTE
The soapsuds utility has a range of command line options to aid clientside
development—see the Microsoft documentation for details. When
using this utility, it helps to remember that wsdl means Web Services
Description Language and -gc means generate code. You’ll then be able
to amaze your friends and colleagues when you can type in soapsuds
commands from memory.
Using Configuration Files
Many settings to the configuration of .NET applications can be achieved not
only inside code but with configuration files as well. All of these files use XML
so that they are humanly readable and easily parsed by the .NET Framework.
With remoting, you can use configuration files to handle all of the work necessary
to expose and consume remoting objects.
www.syngress.com
314 Chapter 6 • Remoting
You use the Configure method of the RemotingConfiguration class to configure
the remoting framework by specifying the configuration file’s location.We now
modify the ListHost hosting application to read a configuration file at startup:
1. Open the ListHost project in Visual Studio.
2. Add a new file to the project called ListHost.exe.config (which is also
located on the CD) with the following contents:
<configuration>
<system.runtime.remoting>
<application name="ListServer">
<service>
<wellknown mode="Singleton" type="
"ListServer.CompanyLists,ListServer"" objecturi="CompanyLists">
<channels>
<channel type="System.Runtime.Remoting.Channels.Http.HttpChannel,
System.Runtime.Remoting" port="8080">
<debug loadtypes="true">
3. Modify the Main() method to use this configuration file on startup
(CompanyListHost3.cs on the CD):
static void Main(string[] args)
{
EventLog myLog = new EventLog();
myLog.Source = "ListHost";
bool failed = false;
try
{
RemotingConfiguration.Configure(@"..\..\ListHost.exe.config");
myLog.WriteEntry("Configuration from ListHost.exe.cfg
successful");
www.syngress.com
Remoting • Chapter 6 315
}
catch (Exception e)
{
myLog.WriteEntry("Failed to configure host application: " +
e.Message,System.Diagnostics.EventLogEntryType.Error);
failed = true;
}
if (failed)
{
System.Console.WriteLine("Errors at startup - see Event Log.");
}
System.Console.WriteLine("Press [Enter] to exit...");
System.Console.ReadLine();
}
Note that while running the host application in the Visual Studio IDE, the
bin\debug directory will contain the executable.You’ll therefore need to use the
“..\..\” syntax in the file path to reach the configuration file in your source code
directory. A further improvement would be to use a command line argument to
specify the CFG file location.This would help during deployment, and you could
test out a variety of configuration options easily without recompiling.
Configuration files may also contain multiple channels definitions and object
URI entries.
NOTE
The Microsoft standard for configuration files is that they should have
the same name as the assembly, but with a .config extension. For
example, myapp.exe will have the configuration file myapp.exe.config.
This configuration file must be placed in the same directory as the
assembly to enable utilities such as the .NET Framework Configuration
tool to locate configuration information.
www.syngress.com
316 Chapter 6 • Remoting
The type parameter is of the format type=“TypeName,AssemblyName”.These
parameters can be difficult to debug if they are wrong—no error message will be
displayed during the call to RemotingConfiguration.Configure.To help with debugging,
the <debug loadtypes="“true”"> attribute has been added, which causes the
types specified in the configuration file to be loaded.Any errors in the spelling of
a type name will then appear as a FileNotFoundException type exception.
On the client side a slightly different configuration file can be used:
<configuration>
<system.runtime.remoting>
<application name="ListClient">
<client>
<wellknown type="ListServer.CompanyLists, ListServer"
url="http://localhost:8080/CompanyLists">
<channels>
<channel type="System.Runtime.Remoting.Channels.Http.HttpChannel,
System.Runtime.Remoting">
The client code also uses the Configure method of the RemotingConfiguration
class to read the configuration file on startup.A client that uses a configuration
file still needs a reference to the remoting application’s DLL but can use the new
keyword to instantiate the class.The client-side configuration actually redirects
the object creation to the server and returns the remote reference. By using this
method, it can be difficult to know if you are successfully creating the remote
object. A mistake in the configuration file can cause the object to be instantiated
locally instead of remotely.To avoid such subtle bugs, you can simply close down
the remote hosting application and make sure that the object creation code
causes an exception when running the client.
www.syngress.com
Remoting • Chapter 6 317
www.syngress.com
Remoting Applications
Remoting applications on the .NET platform have a great deal of flexibility
as to how objects communicate with one another. It is even possible
to “plug-in” your own (or a third party’s) functionality to handle
custom formatting, encryption, and more. This makes it all the more
important for remoting issues to be considered up front in any design
work. The areas that need to be examined include the following:
Should objects be sent over the network by value or by
reference?
How large are these objects?
How often will these objects need to be sent?
For every remote method call, how many bytes of data
would a typical call contain?
How many client applications will a Singleton object need to
handle?
What are the lifetime issues with these objects? (that is, for
how long must they maintain state?)
Can a stateful object be used to increase performance?
Will your firewalls allow your remoting calls through?
Do your server-side objects need to call back to the clients? If
so, will these clients have their own firewalls?
If you need to shut down a hosting application to upgrade
the server object, how will the clients handle this?
Deployment of remoting applications seems quite easy—and
indeed it is. You could send the client-side executables with their con-
figuration files via e-mail to a friend and he would only need to copy
them to a directory and double-click the EXE to get started.
But wait, what happens if you want to move your server-side objects
to another server? When version 2 of the server-side functionality is
released, how do you let the client-side applications know? The solution
to these issues is largely dependent on the type of applications you
create, whether they are Internet- or intranet-based, and the number of
clients that must be administered. One idea to get you started is to have
Developing & Deploying…
Continued
318 Chapter 6 • Remoting
Updating Configuration Files Using
the .NET Framework Configuration Tool
Most developers are happy to use Notepad to update configuration files, but as the
number of files increases, locating the necessary files in the directory tree can be
troublesome.The .NET Framework provides you with a Microsoft Management
Console (MMC) snap-in that serves as a central location for .NET configuration.
Although in Beta 2 this snap-in appears to still need some improvement, it does
hold promise of being a very useful tool.To start the snap-in, open a command
prompt window and change the current directory to the installation directory of
the .NET Framework, which will be WINNT\Microsoft.Net\Framework\vx.y.z
(where WINNT is your windows directory and x.y.z is the version of the .NET
Framework).Type mscorcfg.msc to start the .NET Framework Configuration
tool.You will see a screen similar to Figure 6.6.
www.syngress.com
your client configuration files actually located on your Web server. This
would need to be a server that is almost guaranteed not to have a
domain name change. Instead of having thousands of client configuration
files distributed around the globe—you now have only one. When
client applications start up, they can get the configuration file via HTTP
from your server and always have the latest version.
Figure 6.6 The .NET Framework Configuration Tool
Remoting • Chapter 6 319
To add ListHost.exe to the Applications node, simply click the Add an application
to be configured hyperlink and select the ListHost.exe file from the
dialog. As long as your configuration file is named ListHost.exe.config and located
in the same directory as the executable, you’ll be able to modify the remoting
configuration settings.To update the settings, right-click the Remoting Services
node under ListHost.exe and select Properties from the context menu.
Changing the Hosting Application to a Service
Hosting all of your remoting objects from console applications does appear strange
at first sight. It’s the 21st century and we still haven’t completely got rid of those
character-based applications! The fact is that console applications do provide a
good environment for debugging applications that use remoting—you can immediately
see if your hosting application is running, and you can easily send debug
messages to the console window in real-time while you run your client-side app.
Once your server-side classes are ready for deployment, a Windows Service
provides a better hosting environment. System administrators can easily start and
stop your service, you can view your service from within Visual Studio’s new Server
Explorer, and you can guarantee that your service will be started after a reboot of
the server.The service application we will create is located under the ListService
directory on the CD.
yzs
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
