You have a Collection of Products. Every product effectively maps to an Item. Now I needed to bind this Product collection to a grid and display the item name. So basically it would be something like prod[i].Item.Name or any other property can be accessed for item. Basically the idea is to Iterate over an inner member inside every element of the parent collection.
If you wanted to bind this with a GridView you can have very complex Databinding syntax for this by casting the items etc. Another option that I wanted to bring up here is creating an IEnumerable view using the parent collection.
public class ProdItemList:IEnumerable
{
private List<Product> Products;
public ProdItemList(List<Product> products)
{ this. Products = products; }
public IEnumerator GetEnumerator()
foreach (Product product in Products)
yield return product.Item;
}
You can then bind the DataSource and it would effectively bind to the properties in Item. With something like ItemGrid.DataSource = new ProdItemList(products);
I really liked this article regarding IEnuerable and 2.0. I am sure there are many approaches for this but just thought i'd put it down here for further discussion.
This was a very simple requirement to hide the currently updating controls. I first ran to the the forums and came across this. The trick was quite simple. When we depend control inside the updatePanel this technique fails. The idea is to wrap the update panel inside say another container like a div and set the control ID to that. The below script triggers the hiding of the control and kicks off the UpdateProgress.
<script type="text/xml-script">
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
<components>
<control id="GridContent" visibilityMode="Collapse">
<bindings>
<binding dataContext="_PageRequestManager" dataPath="inPostBack" property="visible" transform="Invert" />
</bindings>
</control>
</components>
</page>
</script>
Atlas rules :)
For those of you guys who arent convinced yet, I have attached a hello world version to this.
When we try to generate a proxy out of an ASMX service with svcutil, there might be some interesting scenarios. One that I came across is when the service exposes types that have a root namespace. Now if you had only that type as the parameter then these doesnt seem to be any issue. As soon as you mix a primitive type with them then you get this error.
E:\Sajay\Visual Studio 2005\WebSites\AsmxDC>svcutil http://localhost:2665/AsmxD
C/Service.asmx?WSDL
Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4312.0]
Copyright (c) Microsoft Corporation. All rights reserved.
Attempting to download metadata from 'http://localhost:2665/AsmxDC/Service.asmx?
WSDL' using WS-Metadata Exchange or DISCO.
Error: An error occurred in the tool.
Error: Wrapper type for message HelloWorldRequest cannot be projected as a data
contract type since it has multiple namespaces. Consider using the XmlSerializer
using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Serialization;
[XmlRoot(Namespace="http://mywebSite/Types")]
public class Item
public string Name;
public string Description;
[WebService(Namespace = "http://myWebsite/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service : System.Web.Services.WebService
[WebMethod]
public string HelloWorld([XmlElement(Namespace = "http://mywebSite/Types")]string name,
Item item)
return name+" says Hello World";
We already have quite a large number of ASMX services and clients. One major point to be kept in mind is that WCF and asmx services can co-exist without any problem and migration to WCF should be your first and only choice unless there is a reason like using security that you do not have already. Or other WS protocols that you need for expanding your serivce.
When migrating there are a number of scenarios one can encounter. One of them is moving an asmx service to WCF withouth changing the undelying client. This would also include not changing the endpoint address to which the client talks to. Now if the client points to something like http://MyServer.com/Service.asmx how can you make this a WCF service? There are 2 main scenarios when doing this.
Without AspNetCompatibility mode.
This is a rather strainght forward approach and can be achieved through the following steps.
1. Add a service host file called service.asmx with the following
<%@ServiceHost language=c# Debug="true" Service="WCFAspCompat.service1" %>
2. Add the following to your web.config file
<system.web>
<compilation>
<buildProviders>
<remove extension=".asmx"/>
<add extension=".asmx" type="System.ServiceModel.Activation.ServiceBuildProvider, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</buildProviders>
</compilation>
</system.web>
With AspNetCompatibility
This requires one more configuration for the httpHandlers and can be achieved with the following steps.
2. You have to remove the .asmx handler initially. Add the following to you Web.config to get this working.
<httpHandlers>
<remove path="*.asmx" verb="*"></remove>
<add path="*.asmx" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
validate="false" />
</httpHandlers>
3. Get your service setup as a aspNet Compatibile service refer this post.
Firstly let us all thank Steve Main . The session/state model is the same that is leveraged by the asp.net framework and hence all the feature of state management comes bundled with it.
On a moral note its the responsibility of using this is upto the designers. But there might be applications and scenarios that may exist or require this to be supported.
The basic steps are quite simple for this.
1. Enable asp.net compatibilty on the serivce hosting environment.
<
2. The service type should next specify the asp.net compatibility requirements. Please keep in mind that this is specified on the ServiceType and not on the Contract as it is the service type that handles the implementation.
[
3. The final piece in this is that the client should enable this stateful communicaiton with the service. This is done by specifying the allowCookies to true in the binding. If you do not enable this then you wont find the session behaving as you want it. You will find that the session for each request is different even if the call is against the same proxy. Another important point to note here is that the session is tied to the instance of the proxy. So with each instance you need to remember thats it comes with a new session. This is the configuration that you have to tie with the endpoint consuming the service.