Check the .Net version of the library and consumer. It should match or lower version.
For some reasons, you may have to run IIS Express x64 from VS2012. For later versions, it is automatically instantiated, however in case of VS2012, it isn’t. And there is no way Microsoft provides any patch or upgrade.
Although there is untestable hack or trick which did work for me.
You have to modify registry to invoke or run IIS Express x64.
Create batch file (*.bat) and put below code.
reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\WebProjects /v Use64BitIISExpress /t REG_DWORD /d 1
Please note: If you are not aware of Parallel Programming, this article is for you else read it for your revision.
Every developer had come across performances issues and lots of brainstorming goes on when customer is not happy with the app performance.
Traditionally, we Improve application performance by – Remove scope of bad-coding, increase application productivity, writing efficient code, improve and optimize SELECT queries, and what not we do to increase and improve application performances, but we tend to forgot that hardware has certain limitation too. Like a single core (processor aka CPU) will execute single thread a time … logical enough. Right? Then comes Asynchronous process into picture, but again with its limitation – defining locks and releasing those, is again a tedious task, and if any is missed, your application will tend to crash. Oh! Did I pointed you can have Async process in ASP.Net to scale your applications and improve performances to certain limit. But this is not parallel programming, its multi-threaded programming.
Parallel vs. Concurrent
Concurrent is accessing the same resources or sharing resources for different problems. old skool example – 2 users accessing same table and even more worse accessing same row. thus increase chance of dead locks.
Parallel is dividing a certain task into a set of related tasks to be executed concurrently. latest example, update tweets/post on twitter.com/facebook using its API to your followers/friends! (Social Media everyone loves it and share latest updates!)
Context of Parallel programming:
Multi-core machines and think of utilizing their power.
Partioning, dividing single piece of work into multiple pieces to execute concurrently.
Staic partitioning, dynamic partitioning, thread pooling.
Model of .Net Parallel Programming:
Task Parallel Library – Task based programming consists of Task Class, Parallel Class, Parallel LIN!(PLINQ).
for (int i, i <= 100, i++)
//Post Wall on Facebook
thread A = addressOf(SendPosts);
thread B = addressOf(SendPosts);
for (int i, i <= 100, i++)
PostIt(“happy friendship day!”);
void PostIt (Account facebook)
//Post Wall on Facebook
System.Threading.Tasks.Parallel.For(0, 10, i =>
//Post Wall on Facebook
By now, you know how to swim in ‘llel programing, its time to deep dive into its ocean. Make sure you are ready with the following kits:
Get’ started – http://msdn.microsoft.com/en-us/concurrency/ee847320.aspx
‘llel programming in .Net 4 – http://msdn.microsoft.com/en-us/library/dd460693.aspx
Blog ‘llel programming – http://blogs.msdn.com/b/pfxteam/
Thread programming in ASP.Net – http://msdn.microsoft.com/en-us/magazine/cc163463.aspx
‘llel patterns – http://parallelpatterns.codeplex.com/
.Net 4.5 is coming with lot of improvements as hardware world is changing with multi-core architecture and soon you will not find the machines with single core and 2 core will soon out-dated.
Try it on vLabs from Microsoft – https://cmg.vlabcenter.com/default.aspx?moduleid=cc0bc14f-b222-4c3b-b29b-7f729df2af08
It did work for me:
If you installed latest version of Silverlight (Silverlight 4), it may break the your current silverlight development environment. After in the Silverlight 4 installation, if you try to debug any Silverlight 3 project, you will get a message from Visual Studio 2008, saying “Unable to start debugging. The Silverlight managed debugging package isn’t installed.”
To fix this error, install the Silverlight Developer Run time. You can get it from here : http://go.microsoft.com/fwlink/?LinkID=188039.
The short-circuiting operators are conditional versions of the logical operators. They conditionally evaluate the second expression as follows:
- x AndAlso y will always evaluate x and will evaluate y only if x is true. (VB)
- x OrElse y will always evaluate x and will evaluate y only if x is false. (VB)
- x && y will always evaluate x and will evaluate y only if x is true. (C#)
- x || y will always evaluate x and will evaluate y only if x is false. (C#)
Virtual Lab: http://go.microsoft.com/?linkid=9644896
this was sometime back webcast: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032378826&Culture=en-US
and if you are looking for developer concepts:
- Sharepoint Planning Guide (1500 pages – did this) – http://office.microsoft.com/download/afile.aspx?AssetID=AM101638541033
- Sharepoint Administration (500 pages) – http://office.microsoft.com/en-us/sharepointserver/FX101211721033.aspx
xmlReader = new XmlTextReader(stream);
DataSet ds = new DataSet();
Understanding how web services work is key to using Visual Studio .NET to build reliable, high-performance distributed applications. With Visual Studio .NET, developers are being encouraged to build applications not as monolithic entities, but rather as individual components that work together. Some of these components may be tightly coupled, communicating via method calls or through named pipes. Others will be loosely coupled, and communicate in more asynchronous ways. A central tenet of .NET development centers on the concept of web services. Web services are a catch-all name for software components that enable other applications to use standard web protocols to access specific features or capabilities of the application. The keys to web services are that they perform functions common to multiple applications, and that they use web standards to communicate and pass information. Web services work best for discrete, compartmentalized tasks that can be done independently of the application making use of them. A web service might, for example, be used to validate credit card accounts for electronic commerce transactions. Virtually every commerce web site has to be able to validate credit cards in order to do business. Without a web service, this means similar code written thousands of different times. Instead, a web service makes it possible for that code to be written only once, and made available at one location, servicing thousands of electronic commerce applications. Web applications call this component to perform that task, take the results returned, and continue processing.
The best analogy to a web service is that of a direct remote procedure call within an application or operating system, or a remote call via CORBA or DCOM. The difference is that these are tightly coupled calls working on architectures that prohibit, or at least restrict, sharing components outside of that architecture. Applications that make use of web services, on the other hand, determine where the appropriate service is located, make a call to the service using web protocols, and wait for the response.
Microsoft provides a seamless and integrated way of developing and using web services with Visual Studio .NET. Because the .NET Framework is built on an application model of multiple communicating web services, Visual Studio .NET was designed with the ability to create such services in much the same way developers would create traditional standalone applications.
The details of web services
How does this application model work? In general, to use web services your applications have to do three things. First, they have to find the appropriate service. Second, they need a way to determine what kind of messages a web service will accept, and in what format. Third, they have to have a communications mechanism to get data to and from the web service. There are standard mechanisms defined for each of these steps. For finding the appropriate service, there are a couple of options. In some cases, an application seeking the use of a web service first uses the Universal Description, Discovery and Integration (UDDI) registry to determine where a specific service can be found. UDDI is a web-based distributed directory that enables web services to list themselves on the Internet and discover each other, similar to a traditional phone book’s yellow and white pages. In other cases, your application may know exactly where to go for a web service. The web service may be an internally developed component, supporting a variety of mission-critical applications. For example, an enterprise may have dozens of applications for different purposes that all require the validation of customer account numbers. Because this approach greatly simplifies the need to search out and have a business agreement with a third-party web service, it will likely be the initial mainstream web services model. Web services are accessed using the Hypertext Transport Protocol (HTTP) as the transport mechanism. The data packets transferred apply the Simple
Object Access Protocol (SOAP), with a payload of XML statements. The XML provides a placeholder for data, either input to the web service or output back to the application. SOAP is a standard of the World Wide Web Consortium, and its specification can be found at http://www.w3.org/tr/soap. It describes an XML-based message passing format for communications between networked computers and other devices. It also contains standards for defining remote method calls and sending packets over HTTP.
The Extensible Markup Language, a superset of the Standard General Markup Language (SGML), simply defines how information is to be formatted on a web page or other document. In that sense, it’s similar to other markup languages, such as HTML. As it turns out, however, XML is an excellent way to format, send and receive data, and invoke method calls. It has the advantage of being a lightweight mechanism, as it consists entirely of text tags. A data structure and method invocation mechanism created using XML tags is referred to as a schema, much like a traditional database schema. A schema will be different for different types of messages, but it is likely that individual web services will respond to only a small set of predefined schemas, or even a single schema.
The architecture of a web service
A web service looks somewhat different than a traditional application. It has an architecture that reflects the needs of a remote component potentially servicing multiple applications. In this sense, the application requesting the service can be referred to as the client for that service. The web service interface to the client is called the listener. The listener accepts a message, parses it to determine the nature of the request, and passes it on to that part of the web service best equipped to handle the request. If the client expects a response to the request (which will happen in most cases), the listener also packages that response as an HTTP SOAP message and sends the response. The listener responsibilities go beyond processing requests for service, however. In cases where the client queries the UDDI for a specific type of service, it provides information about that web service. The remainder of the web service architecture doesn’t require knowledge that it is in fact a web service. It could otherwise be any type of application component. It primarily consists of business logic and data, with a few twists. The business logic may be divided into two parts—the logic itself and a business façade. The logic itself is the computational core of the web service. It performs the primary operations that define the function of the web service. The façade is the interface between the core functions and the listener; if used, it exposes those functions that are described in the listener. This enables a one-to-one correspondence between services and logic that implements those services, an especially simple interface for more complex web services. The data access layer provides an interface between the business logic and the data supporting that logic. The encapsulation of this code into a separate layer offers the potential for reuse of that layer across different web services, and also helps to separate code from data. The last level is the data driving the web service. This data doesn’t include that passed by a service consumer using SOAP. Instead, it’s data needed by the web service to perform its processing. It may contain static data, or be the front end to a standard database.
The similarity of a web service to an ordinary application, in particular one using the Windows DNA architecture, means that some existing applications or COM components could conceivably be enhanced to be web services. In some cases, the only modification that may be required is the addition of the SOAP listener to accept and respond to queries and data input. While this isn’t trivial, it may be easier to adapt a legacy component as a web service than to rebuild similar functionality from scratch.
The key to application communications with web services is SOAP. A SOAP message is a one-way transmission between a sender and receiver using HTTP. Those components are loosely coupled and the communication is asymmetric. The message packages all XML data within an Envelope tag, which is similar to an HTML-style tag, that points to namespace-defining elements within the SOAP message. Within that envelope can be two SOAP-specific components, the Body and the Header. The Body element, which is mandatory, contains most of the request and response information in a SOAP transmission. The optional Header element contains information that can direct SOAP messages not just to one receiver, but to several. The Header can distribute different information from the Body element to each receiver component before the message reaches its final destination. Using information in the Header section, a SOAP message may pass information to several intermediary components before reaching its final recipient.
A Header can contain multiple Header blocks that organize information in the record. For example, an XML application that lets students register for their college courses might have a Header with two Header blocks—one for the student’s name and one for the course name. This structure lets the application catalog the information in two places: a student record showing which courses the student registers for, and a course record that shows who registers in any given course. Each recipient of a SOAP message reads the Header to determine which action to perform with the information in the body—process all or part of the information, pass the information to another recipient, or read the information, for example. How does the SOAP message get from the sender to the recipient? The standard delivery mechanism for SOAP is HTTP—the same protocol that standard web traffic uses. The sender identifies the receiver through the use of a Uniform Resource Identifier (URI), connects to the recipient through the TCP/IP network, issues an HTTP request message and receives an HTTP response message over the same connection.
Sharing information on web services
If you have a web service, you need a method of specifying how it works to other potential consumers. The Web Services Description Language (WSDL) is an XML-based language for describing the capabilities of web services. A WSDL file is an XML document that describes a set of SOAP messages and how the messages are exchanged. In other words, WSDL is to SOAP what the Interface Description Language is to CORBA or COM. Since WSDL is written using XML, it is readable and editable, but in most cases it is generated and consumed by the application. To see the utility of WSDL, imagine that you want to call a SOAP method provided by a partner company that has developed its own web services. You could ask that company for some sample SOAP messages and write your application to produce and consume messages that look like the samples. But without a specification of their format and function, there could be errors. For example, you might see an inventory value of 1674 and assume it’s an integer when in fact it’s a string. WSDL addresses incompatibilities like these by specifying what a request message must contain and what the response message will look like in unambiguous notation. The notation that a WSDL file uses to describe message formats is an XML schema, which means it is both programming-language neutral and standards based.
These characteristics make it appropriate for describing web services interfaces that are accessible from a wide variety of computing platforms and programming languages. In addition to describing message contents, WSDL defines where the service is available (using a URL or URI) and what communications protocol is used to talk to the service. In other words, the WSDL file defines everything required to write a program to work with a web service. There are several tools available to read a WSDL file and generate the code required to communicate with a web service. Most web services have a set of standard operations that are virtually the same no matter what the service does. These operations include activities such as:
• listening for incoming HTTP requests (the listener layer)
• performing authentication and authorization checks (a security portion of the business logic layer)
• dispatching requests to the correct part of the web service (the listener layer)
• ensuring that individual services are isolated from each other and the system running them. Failures in one web service should not cause other services or the overall computing environment to fail.
• Automatically detecting and recovering from service, hosting environment and computer system failures
• providing software administrative facilities for deploying, monitoring and controlling web services
• Managing resources dedicated to web services operation, such as processes, threads and service state.
Fortunately, default facilities for most of these functions are a part of Microsoft Visual Studio .NET. Because Microsoft built Visual Studio .NET with web services in mind, it offers automated methods of implementing some of the most fundamental technologies needed to make web services operational.
Visual Studio .NET and web services
Microsoft positions ASP .NET as a natural technology for implementing web services based on the .NET Framework. ASP .NET web services support requests from clients using SOAP over HTTP, as well as with HTTP GET or POST operations. ASP .NET web services automatically generate WSDL files for web services development efforts. Developers can also use ASP .NET web services to implement a web service SOAP listener that waits for service requests, and accesses a business façade implemented as a COM component or as a managed code class. ASP .NET technologies provide a high-level programming model for building web applications using web forms and web services. ASP .NET supports request authentication, Microsoft Passport authentication and custom cookie based authentication for applications that use a private account database for authenticating users. Web services using ASP .NET in Visual Studio .NET begins with the same concepts you would use in writing any application. Writing web services in Visual Studio .NET involves selecting a web services project as a starting point and implementing the functionality of a web service is no different than writing a traditional application or application component. The web services project creates the necessary files to build a basic service. Instead of the .aspx file extension of an ASP .NET web page, web services are saved in files with the extension of .asmx. Whenever the ASP .NET runtime receives a request for a file with an .asmx extension, the runtime dispatches the call to the web service handler for that service. Handlers are instances of classes that implement the System.Web.IHTTPHandler interface. With this handler, ASP .NET is able to use reflection and can dynamically create an HTML page describing the service’s capabilities and methods. ASP.NET also makes it straightforward to define and publish WSDL specifications and contracts. Visual Studio .NET takes care of requesting a WSDL contract from a remote web service via HTTP and generating a proxy class for the service. Another worthwhile aspect of the web service handler under ASP .NET is that it creates a simple test web page for your services. This test page allows you to confirm that everything is working with your web service without having to write your own test client. Among the other Visual Studio .NET and features available for building web services are:
• The Microsoft SOAP Toolkit version 2 can be used to build a web service listener
• Unmanaged COM components can be used implementing the business façade, business logic and data access layers. These can be existing COM components or new ones.
• ADO, OLE DB and ODBC can be used to implement data access to a variety of different data stores
• XML services to help construct XML messages within the web service listener.
Web services offer the potential to become a major force in application development. By making software components available in a web services model, enterprises can make agile use of custom software functions, designing each to perform and optimize a specific piece of the business process. According to research done by Gartner, by 2003 more than 40 percent of all Internet-oriented interactions will leverage web components from multiple enterprises, and by 2004 web services will dominate deployment of new application solutions for Fortune 2000 companies. Web services may also simplify application development. The ability to break applications down into smaller functional components has the potential to make individual components more reliable. However, nothing in computing is ever free, so the simplification of individual application components may not mean the application as a whole is any more reliable. There may be reliability or performance issues that aren’t apparent until the web service is used as a part of a larger, distributed application. As a result, the application development process for web services is likely to change. Developers will likely become more dependent upon software development tools that provide the ability to analyze and test web services and other application components separately, and provide some initial testing of the overall application. However, it’s increasingly likely that all of the components comprising the application will be brought together later in the development cycle
Than in the past, leaving it to testers to ensure the reliability, performance and scalability of the application. To accelerate this type of methodology, application developers and testers require tools that find and analyze errors and performance issues in individual components as well as distributed applications. Testers must be able to use data generated by developers and to easily share information across the development cycle. Only if the development and testing teams work together will web services have the potential to deliver the value expected with the quality required.