.NET AnswerBank - a free site for anybody to post questions .NET QUESTION With ANSWER
Smart clients are client applications that consume Web services and reside on user hardware such as desktop PCs, laptops, Pocket PCs, and Smartphones. They are easily deployed and managed and provide an adaptive, responsive, and rich interactive experience by taking advantage of the computing resources on the device and intelligently connecting to distributed data sources.
When you try to debug an ASP.NET application in Visual Studio.NET. you may receive the following debugging error.
Error while trying to run project: Unable to start debugging on the web server. The project is not configured to be debugged.
Following are reasons and solutions for this problems.
Possibility 1:
You are not a part of debugger group.
Solution
Local Users and Groups ->Users- > add yourself as a Debugger User (Also check if you are a VSDeveloper
Possibility 2:
You dont have execute permissions on your virtual folder.
Solution
Step 1: Control Panel -> Administrative Tools- >Internet Service Manager
Step 2: Default Web Site -> Right Click on your Project-> Properties->Execute Permissions -> Scripts and Executables
Possibility 3:
You have kept ASP.NET debugging unchecked.
Solution
In VS.NET IDE,
Right Click Project - >Properties->Configuration Properties ->Debugging-> Debuggers Enable Check the checkbox for ASP.NET Debugging
ASP.NET Server Controls
Advantages:
1. ASP .NET Server Controls can however detect the target browser's capabilities and render themselves accordingly. No issues for compatibility issues of Browsers i.e page that might be used by both HTML 3.2 and HTML 4.0 browsers code to be written by you.
2. Newer set of controls that can be used in the same manner as any HTMl control like Calender controls. (No need of Activex Control for doing this which would then bring up issues of Browser compatibility).
3. Processing would be done at the server side. In built functionality to check for few values(with Validation controls) so no need to choose between scripting language which would be incompatible with few browsers.
4. ASP .NET Server Controls have an object model different from the traditional HTML and even provide a set of properties and methods that can change the outlook and behavior of the controls.
5. ASP .NET Server Controls have higher level of abstraction. An output of an ASP .NET server control can be the result of many HTML tags that combine together to produce that control and its events.
Disadvantages:
1. The control of the code is inbuilt with the web server controls so you have no much of direct control on these controls
2. Migration of ASP to any ASP.NET application is difficult. Its equivalent to rewriting your new application
HTML Server Controls
Advantages:
1. The HTML Server Controls follow the HTML-centric object model. Model similar to HTML
2. Here the controls can be made to interact with Client side scripting. Processing would be done at client as well as server depending on your code.
3. Migration of the ASP project thought not very easy can be done by giving each intrinsic HTML control a runat = server to make it HTML Server side control.
4. The HTML Server Controls have no mechanism of identifying the capabilities of the client browser accessing the current page.
5. A HTML Server Control has similar abstraction with its corresponding HTML tag and offers no abstraction.
Disadvantages:
1. You would need to code for the browser compatibility.
HTML Intrinsic Controls
Advantages:
1. Model similar to HTML
2. Here the controls can be made to interact with Client side scripting
Disadvantages:
1. You would need to code for the browser compatibility
After you install Microsoft Visual Studio .NET or the Microsoft .NET Framework, When you try to access any aspx page. If the ASPX page is not coming or if controls or not appearing in the Page. Then this could be caused because of wrong asp.net installation.
To configure asp.net properly in IIS Just follow these steps.
Dot net framework provides an Administration utility that manages the installation and uninstallation of multiple versions of ASP.NET on a single machine. You can find the file in C:\WINNT\Microsoft.NET\Framework\v1.0.3705\aspnet_regiis.exe (This folder might change depending upon on you framework installation folder)
Then uninstall current ASP.NET Version using following Command,
aspnet_regiis.exe -u
For again installing ASP.NET, Use following command.
aspnet_regiis.exe -i
To know more about aspnet_regiis, check out this link.
SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.
To get a quick sense of SOAP, here is a sample SOAP request to a weather service (with the HTTP Headers omitted):
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
As you can see, the request is slightly more complicated than XML-RPC and makes use of both XML namespaces and XML Schemas. Much like XML-RPC, however, the body of the request specifies both a method name (getWeather), and a list of parameters (zipcode).
Here is a sample SOAP response from the weather service:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
*
*
*
*
The response indicates a single integer return value (the current temperature).
The World Wide Web Consortium (W3C) is in the process of creating a SOAP standard. The latest working draft is designated as SOAP 1.2, and the specification is now broken into two parts. Part 1 describes the SOAP messaging framework and envelope specification. Part 2 describes the SOAP encoding rules, the SOAP-RPC convention, and HTTP binding details.
Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system
XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and desirable) properties:
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL).
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration
