What's New in the Visual Studio 2005 IDE

Review the host of improvements and new features that make the Microsoft Visual Studio 2005 integrated development environment (IDE) even more impressive than its predecessors.

http://msdn.microsoft.com/library/default.asp?url=/library
/en-us/dnvs05/html/vs2005icons.asp

.Net Remoting vs Web Service

.NET remoting

While Web services are arguably the best way for clients outside of your organisation to access components, what about components within your organisation? Many companies are building Web services and using them internally. There is nothing wrong with this approach, but it doesn't provide the best performance. If components are created in .NET and the client applications are .NET, you can place components on shared servers and access them via remoting.

Remoting is the .NET technology that replaces DCOM allowing you to communicate between a client application and components in a binary format. As a result, remotable components are faster than Web services. However, creating remotable components is more difficult because you must add additional code to your components. This code isn't much more complicated than its Web service counterpart, but you cannot directly instantiate a remote component. Instead, you must create a host application that instantiates the component and listens for requests. The good news is that this host can be a Windows service, a Windows application, a console application, or anything that can run and hold the object open.

Not only do you have to create a host application, you must also make several decisions about the remotable object, such as which channel to use. .NET supports both HTTP and TCP channels. The HTTP channel actually uses the SOAP protocol to transport messages to and from remotable objects; this means all messages are serialised to XML. The TCP channel uses a binary stream to transport the messages.

Next, you must choose between two activation modes: Singleton and SingleCall. Singleton types have only one instance of an object at any time. All client requests are serviced by that single instance. This allows you to "share" data between requests or, more likely, maintain state between requests. SingleCall types, on the other hand, create a new instance of the object for each client request. SingleCall objects are more like Web services because they are stateless and are created and destroyed for each request.

.NET is architected in such a way that remotable components can change channels without being recompiled. You can place the channel information in a configuration file and change from TCP to HTTP or vice versa without recompiling the application. Similarly, you can change a configuration file for the client to match the channel that the host is using.
Quick code comparisons
The entire code for the Web service follows:

<%@ WebService Language="VB" Class="ConvertMoney" %>
Imports System.Web.Service
Public Class ConvertMoney
Inherits WebService
Public Function _
PoundsToDollars(BritishPounds As Double) As Double
Return BritishPounds * 1.44
End Function
End Class

Here is the code to implement the same thing with a remotable component:

Public Class ConvertMoney
Inherits System.MarshalByRefObject
Public Function _
PoundsToDollars(ByVal BritishPounds As Double) As Double
Return BritishPounds * 1.44
End Function
End Class

The component looks simpler. In fact, the only difference is that it inherits from System.MarshalByRefObject. But remember, you need to build a host application that instantiates the object and listens for requests. The code for the host object could look like this:

Imports System.Runtime.Remoting
Imports System.Runtime.Remoting.Channels
Imports System.Runtime.Remoting.Channels.Tcp
Imports RemoteConvertMoney
Module Module1
Sub Main()
Dim tcpChannel As New TcpChannel(7777)
ChannelServices.RegisterChannel(tcpChannel)
Dim ChangeMoney As New ConvertMoney
RemotingServices.Marshal(ChangeMoney, "ConvertMoney")
Console.ReadLine()
End Sub
End Module

In this case, the host application is a console application. You start the application and it launches a console application and creates the object. The console application runs until someone presses the [Enter] key, and the object is available until needed.

As you can see, the amount of work required to create the remotable component is more than the Web service.

Make the choice
There is no absolute answer to whether you should choose Web services or remoting in most cases. If your entire distributed application is inside your organisation firewall and performance is critical, remoting via the TCP channel is the best choice. If the entire application is inside the firewall and performance isn't as critical, or if you want to keep things as simple as possible, Web services is a better choice.

But, if you need to allow access to clients other than .NET, you'll need to use Web services regardless of whether or not the client is inside or outside the firewall. In the end, the choice is left to the developer, so you'll need thorough knowledge of both technologies to make a proper decision.

What is .Net Remoting?

.NET Remoting is an enabler for application communication. It is a generic system for different applications to use to communicate with one another. .NET objects are exposed to remote processes, thus allowing interprocess communication. The applications can be located on the same computer, different computers on the same network, or even computers across separate networks.

.NET remoting versus Distributed COM

In the past interprocess communication between applications was handled through Distributed COM, or DCOM. DCOM works well and the performance is adequate when applications exist on computers of similar type on the same network. However, DCOM has its drawbacks in the Internet connected world. DCOM relies on a proprietary binary protocol that not all object models support, which hinders interoperability across platforms. In addition, have you tried to get DCOM to work through a firewall? DCOM wants to communicate over a range of ports that are typically blocked by firewalls. There are a ways to get it to work, but they either decrease the effectiveness of the firewall (why bother to even have the firewall if you open up a ton of ports on it), or require you to get a firewall that allows support for binary traffic over port 80.
.NET Remoting eliminates the difficulties of DCOM by supporting different transport protocol formats and communication protocols. This allows .NET Remoting to be adaptable to the network environment in which it is being used.

.NET Remoting versus Web Services

Unless you have been living in a cave, or are way behind in your reading, you have probably read something about Web services. When you read the description of .NET Remoting it may remind you a lot of what you're read about Web services. That is because Web services fall under the umbrella of .NET Remoting, but have a simplified programming model and are intended for a wide target audience.
Web services involve allowing applications to exchange messages in a way that is platform, object model, and programming language independent. Web services are stateless and know nothing about the client that is making the request. The clients communicate by transferring messages back and forth in a specific format known as the Simple Object Access Protocol, or SOAP. (Want to get some funny looks in the hallway? Stand around in the hallway near the marketing department with your colleagues and discuss the benefits of using SOAP).

The following list outlines some of the major differences between .NET Remoting and Web services that will help you to decide when to use one or the other:

· ASP.NET based Web services can only be accessed over HTTP. .NET Remoting can be used across any protocol.

· Web services work in a stateless environment where each request results in a new object created to service the request. .NET Remoting supports state management options and can correlate multiple calls from the same client and support callbacks.

· Web services serialize objects through XML contained in the SOAP messages and can thus only handle items that can be fully expressed in XML. .NET Remoting relies on the existence of the common language runtime assemblies that contain information about data types. This limits the information that must be passed about an object and allows objects to be passed by value or by reference.

· Web services support interoperability across platforms and are good for heterogeneous environments. .NET Remoting requires the clients be built using .NET, or another framework that supports .NET Remoting, which means a homogeneous environment.

SOS from your production environment

All the best software development practices and testing efforts in the world can not guarantee that there are no intermittent or unexplainable application issues when in production. Worst case scenario being application hangs and crashes. This article shows how to take dumps of .NET applications and analyze them. This helps developers to understand the issue and find the faulty code.

For More info please refer the following Link
SOS from your production environment

How to find out if proxy is enabled in the local computer

There are couple of ways we can retrieve the proxy settings in C# or VB.NET.

Method 1 : Read the settings directly from the registry.

When we change the proxy settings thorugh Internet Explorer, the settings is stored in the registry. We can read the registry values to check if the proxy is enabled and find the proxy server.

Microsoft.Win32.RegistryKey key =
Microsoft.Win32.Registry.CurrentUser.OpenSubKey("Software\Microsoft\\Windows\\CurrentVersion\\Internet Settings");

string proxyEnabled = key.GetValue( "ProxyEnable" ).ToString();

The following code will return the proxy server address specified in the IE settings, even if it is not enabled.

string proxyServer = key.GetValue("ProxyServer") == null ?
   string.Empty : key.GetValue("ProxyServer").ToString();

Method 2 : We can use the Webproxy class to get details about the current proxy settings.

System.Net.WebProxy webProxy = System.Net.WebProxy.GetDefaultProxy();

bool bypassProxyForLocal = webProxy.BypassProxyOnLocal;  

Uri address = webProxy.Address;
if ( address != null )
{
string host = address.Host;
string port = address.Port.ToString();
}

Using the WebProxy class is a better solution. It exposes various properties using which we can retrieve information related to the proxy settings including port number, host address etc. Reading from registry directly returns a single string, which we may need to parse to extract the host address and port number.

Indigo - Service oriented architecture

Service orientation is a means for building distributed systems. Fundamental to the service model, is the separation between the interface, and the implementation. The invoker of a service need only understand the interface;

A service is nothing but a unit of work done by a service provider to achieve desired end results for a service consumer.

In fact Service orientation is a complement of object – orientation. Object orientation, focuses on the applications that are built from interdependent class libraries. However service-oriented development focuses on the systems that are built from autonomous services.

Microsoft decided to combine all these 4 stacks into a cleaner and a powerful stack and named it as Indigo services.

Interoperable Web Services - ASMX model
.NET – .NET Communication - .Net Remoting
Distributed Transactions - COM+ services
Queued Messaging - MSMQ

In the future the answer for all the above technological requirements is Indigo services.
Basically the protocol that indigo uses in the wire is SOAP which is a standard in the web services across all platforms.

Creation of service is easier. Each service will have 1 or more end points that are accessible by service consumers, and a Meta data information.

The "Indigo" service model makes service-oriented development explicit and simple from any CLR-targeted language.. The "Indigo" service model supports two kinds of contracts: service contracts and data contracts.

A service contract describes the pattern of message exchanges that are used to interact with a service. Service contracts are analogous to Web Services Description Language (WSDL) portType definitions.

Data contracts are structural in nature and describe the external format of a CLR type. A data contract is analogous to an XML schema definition.

To Create the Indigo service:

Step 1: Import The system.collections.generic;
Step 2: Create a Interface and provide the declaration of the methods that the service will offer. Methods will be declared with operationcontract attribute
Step 3: Mark the interface with ServiceContract attribute. It has two properties Name, Namespace.
Step 4: Create a class that implements your service interface and provide the Definition for the method declared in the interface here.
Step 5: Client.
Create the binding, Service host and URI objects here.
Step 6: Add end points to the service host.
Call the service methods. That’s it. You have your indigo service.

Hosting Indigo Services:

A class implementing an Indigo service is compiled into a library. Indigo provides two options for hosting libraries that implement services.
1. Use a host app domain and process provided by the Windows Activation Service
2. Host the service in any app domain running in an arbitrary process.
Indigo will use the SOAP Message Transmission Optimization Mechanism (MTOM) for the attachment technology. More over Indigo will support transactions and synchronous and asynchronous messaging and peer-peer interaction.
Begin building services that will be compatible with the Indigo services when released.