Asp.net and c#

Outlook 2003 as an Object Model Microsoft has a long history of exposing an application's functionality to external programs. For example, if your project requires spell-checking functionality, you can leverage the object model exposed from Microsoft® Word. In a similar vein, if you are building an application that requires the functionality supplied by Microsoft® Outlook® 2003, you can leverage the associated object model. In a nutshell, the Outlook 2003 object model allows you to interact with: E-mail items. The Outlook Contacts database. The Outlook Calendar. Outlook Notes and Tasks. The UI of Outlook itself (Explorers, Inspectors, CommandBars, etc). This is obviously a subset of the contained functionality, but I'm sure you get the general idea: The functionality of Outlook 2003 can be accessed via its associated object model. See more: http://msdn.microsoft.com/en-us/library/aa289167.aspx

Introduction: ASP.NET Web services and .NET Remoting provide a full suite of design options for cross-process communication in distributed applications. In general, ASP.NET Web services provide the highest levels of interoperability with full support for WSDL and SOAP over HTTP, while .NET Remoting is designed for common language runtime type-system fidelity and supports additional data format and communication channels. ASP.NET Web Services: ASP.NET provides a Microsoft® IIS-hosted infrastructure that supports industry standards such as SOAP, XML, and WSDL. Although.NET Remoting supports IIS hosting and SOAP over HTTP, ASP.NET is designed to provide the highest level of SOAP interoperability including support for SOAP Section 5 and document/literal. ASP.NET can leverage the features available with IIS, such as security and logging. IIS hosting is also robust in that it will re-spawn Aspnet_wp.exe if it terminates. Also, ASP.NET Web services are much easier to create and consume than s

.NET remoting enables you to build widely distributed applications easily, whether application components are all on one computer or spread out across the entire world. You can build client applications that use objects in other processes on the same computer or on any other computer that is reachable over its network. You can also use .NET remoting to communicate with other application domains in the same process. (For details about programming application domains, see Programming with Application Domains.) .NET remoting provides an abstract approach to interprocess communication that separates the remotable object from a specific client or server application domain and from a specific mechanism of communication. As a result, it is flexible and easily customizable. You can replace one communication protocol with another, or one serialization format with another without recompiling the client or the server. In addition, the remoting system assumes no particular application model. You c

Introduction Microsoft® ASP.NET view state, in a nutshell, is the technique used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks. In my experiences as a trainer and consultant, view state has caused the most confusion among ASP.NET developers. When creating custom server controls or doing more advanced page techniques, not having a solid grasp of what view state is and how it works can come back to bite you. Web designers who are focused on creating low-bandwidth, streamlined pages oftentimes find themselves frustrated with view state, as well. The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE. This hidden form field can easily get very large, on the order of tens of kilobytes. Not only does the __VIEWSTATE form field cause slower downloads, but, whenever the user posts back the Web page, the contents of this hidden form field must be posted back in the HTTP request, thereby lengthening the request time, as we