After spending several hours trying to implement what is described here:

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4429

... I am still cannot convince VS.net 2005 to generate correct Web service proxies. This process is very poorly documented and I cannot get all the pieces together.

Could we have a step-by-step tutorial ASAP?!? After all, it is promised here: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4595&HighLight=1

Regards,

Denis

susacd wrote:

After spending several hours trying to implement what is described here:

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4429

... I am still cannot convince VS.net 2005 to generate correct Web service proxies. This process is very poorly documented and I cannot get all the pieces together.

I hope you're referring to the ms documentation on this, as that's indeed pretty poor. Officially the .NET 2.0 webservice stuff isn't supported yet.

Could we have a step-by-step tutorial ASAP?!? After all, it is promised here: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4595&HighLight=1

it's moved to the v2.0 version. The templates available in the 3rd party section are... 3rd party offerings which you can use to add additional functionality. We don't supply support for 3rd party offerings. I understand you're frustrated, but trust me, you can't be half as frustrated over this whole process as I am.

For v2.0 we'll add official support for it, till then you have to work with the templates offered in the 3rd party section, and check the thread you referred to. We also can't work with 'it doesn't work', please state what exactly is wrong, and what you've tried.

Well I can move this discusion to the thread we are reffering to... Or I can ask the original author to add a simple README file to the download.

We are offered with two template and two config files without any documentation, not to mention that one of them contains raw "&" character which of course isn't allowed in the XML file and the whole thing chrashes. Nobody says where to put those files and what to do with the generated files. (correction: I now see the latest messages in that thread that just confirm what I'm saying)

OK, I figured out much of that stuff on my own (but not completely), but 60 mins. spent on writing a simple step-by-step tutorial (since it is a rather sequential process) would save us all days of work. Heck, I would do it myself and post it to this forum if I could put the damn thing to work

Cheers,

Denis

Again, I understand your frustration, and indeed having a readme with the templates would make them more useful. Nevertheless, they're more of a 'proof of concept' than a 1-2-3 applyable piece of code. This comes from the fact that the templates are a result of a lot of trial/error coding as you could see in the thread.

(edit): I'll see if I can update the template archive with a more applicable version tomorrow. No promisses, but I'll try.

Thanks. Regardless of the WSDL tool misbehavior, LLBLGen is still the best tool in its category, not to mention your great support. Cannot wait for the next version...

susacd,

What exactly isnt working? the WSDL when you hit update the web reference? or the code not generating?

The whole process is very finicky. Make sure that after you edit your machine.config file OR add the schemaimporter assembly into the GAC that you restart visual studio!!!

Also add some message box code to the beginning of the function in the schemaimporter to make sure it getting loaded

The templates are more of a proof of concept, they are by no means a polished 3rd party addon, and i didnt want to spend any more time then i needed to on them since its going to be supported in 2.0. However, many people were interested so i threw up what i had so other developers could leverage it and of course frans would have a headstart for its support in 2.0.

Answer wrote:

susacd,

What exactly isnt working? the WSDL when you hit update the web reference? or the code not generating?

Let me explain my current project setup:

Dennis.Project.Data (contains entities, LLBLGen generates this) Dennis.Project.DataDBSpecific (contains DB specific stuff, , LLBLGen generates this) Dennis.Project.Service (my webservice) Dennis.Project.Client (my Windows client)

I have a problem as well... The generated proxy does not include my business entities assembly in the usings. Mine is called "Dennis.Project.Data" (and "Dennis.Project.DataDBSpecific"). The Dennis.Project.Data.dll isn't included as a reference and also not as a using.

Then the EntityCollection is refers to in the proxy, is "Dennis.Project.Client.Project.Service.EntityCollection". This isn't good! When I place "Dennis.Project.Data.HelperClasses.EntityCollection" on the spot that said "EntityCollection", everything does work.

But when I try to cast it (in my client app) to that specific type, the compiler says I can't do that.

It seems the SchemaImporterExtension doesn't do ANYTHING. How come?

Regards, Dennis

It does something, as it would otherwise solely contain DataSet types instead of collections/entity types.

It can be the template misses a root namespace tag here and there.

Whoops, my fault. It works! I updated the SchemaImporterTemplate a bit, and will post tomorrow what I changed. Nothing ground breaking. I made a huge mistake in the machine.config, that's why it didn't work.

dvdstelt wrote:

Whoops, my fault. It works! I updated the SchemaImporterTemplate a bit, and will post tomorrow what I changed. Nothing ground breaking. I made a huge mistake in the machine.config, that's why it didn't work.

Cool! I already wondered why it didn't work at your place . Nevertheless, it's a tough job to get it all working, unfortunately, thanks to the hacky design MS cooked up for this...

Hehehehe...

I found out, part of the reason is, the IXMLSerializable interface was also seen as the ISupportDataSet interface. In .NET 1.1 is solely existed to support DataSet deserialization. That's why the WSDL sees an IXMLSerializable interface and directly translates this into a DataSet.

What strange is, is that this still occurs in .NET 2.0, as this should not happen anymore, if I'm correct.

(I'll update this thread with my promised change/solution later on)

dvdstelt wrote:

Hehehehe...

I found out, part of the reason is, the IXMLSerializable interface was also seen as the ISupportDataSet interface. In .NET 1.1 is solely existed to support DataSet deserialization. That's why the WSDL sees an IXMLSerializable interface and directly translates this into a DataSet.

It's actually hardcoded in the wsdl.exe toolkit, according to MS. The schema specifications used by the wsdl tool don't contain any type info. This means that the only type it can fall back on is the dataset. (as the datatable doesn't have xml export code in .net 1.x anyway ).

What strange is, is that this still occurs in .NET 2.0, as this should not happen anymore, if I'm correct.

(I'll update this thread with my promised change/solution later on)

By default it still does that, to stay backwards compatible. Though with attributes you now can add information to the schema which is used on the client to produce types (whoever cooked this up should simply do something in marketing/sales ...) via complex classes registered in the machine.config (something which should signal all red flags available).

Instead of simply adding type information to the schema which is used by the wsdl directly, it goes through a myriad of hoops. It's not flexible, easy and solid as you've experienced: do one thing wrong and it falls apart and you're in the dark for days.

It is hard because the evaluation to change our companies architecture to LLBL is based on being about to use it with Web Services and SSIS. The 3rd party templates do not seem to help when the consumer is SSIS. My question for now is, should I just iterate though the EntityCollection and build my own soap message (XMLDocument) and send that back though the Web Service? What other suggestions do you have until the framework can support Web Services .Net 2.0?

Maybe build a Class that functions like the EntityCollection except takes the Entity objects and creates XMLNodes and append them in the XMLDocument as elements.

Syntax like this: (create a soap object that serializes a XMLDocument instead of the EntityCollection)

EntitySoapCollection soap = new EntitySoapCollection( new CEntityFactory() );

and maybe excepte a parameter of EntityCollection/Entiity object:

DataAccessAdapter adapter = new DataAccessAdapter( ); EntityCollection customer = new EntityCollection new CustomerEntityFactory( ) ); adapter.FetchEntityCollection( customer, null ); EntitySoapCollection soap = new EntitySoapCollection( customer );

Any suggestion to patch this for now until LLBL 2.0

Thanks.

What's SSIS? That new system for sqlserver 2005 which replaces DTS?

You can already serialize an entity collection (or entity) to XML with entitycollection.WriteXml(), and you can pass in an XmlDocument or string or what have you.

The 3rd party webservices templates will be the boilerplate work for v2's webservices support, as there's not that much more possible for us unfortunately. MS has designed this and in a bad way, they updated it a bit in .net 2.0 to overcome hardwired type evaluation, but it's not as simple as it could have been...

Yes, SSIS seems to be the replacement of DTS. The serialization is not the problem, it is the consuming the XML without making a reference to the business objects.

Am I overlooking something in the 3rd party webservices templates. It seems that when consuming the webservice (setting a WebReference) in a winform or website project it seems that you must make a reference the generated LLBL object to get the project to complile. This is the problem, I can not make a reference to the generated LLBL in SSIS.

After making a web_reference I get this error.

The type or namespace name 'InternalWS' could not be found (are you missing a using directive or an assembly reference?)

Once I make a reference to the dll where the EntityCollection class is contained it will build. Is this the WSDL that is causing this or something that I am missing.

Thanks.

the generated stub classes refer to that. Please check the generated stub class. It's otherwise impossible to make this work, as you apparently return a type known in an assembly you dont want to refer to and IMHO you won't be able to do this obviously.

Thank for the direction,

I compared the stub class to a working webservice and found that the stubs was incomplete. It was missing the class stubs and its interfaces, plus a few other things as well.

This code is not being generated, plus I think the interfaces of the object need to be generated as well.

 /// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.26")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute Namespace="http://Shuyun.Pubs/xml/serialization")]
public partial class EntityCollection
{

}

Still trying to understand, thanks of the help.

please forgive me, but I've no idea what you're saying. What exactly is wrong with the generated code produced by the webservice templates (Which work) ?

sburtonctr:

LLBLGen entities were never designed to be sent across web services, can it be done? yes, but they are slow, heavy and just not elegant, IMHO. A better option and the one that i am taking is to use the excellent llblgen framework to generate a 2nd set of POCO classes and a converter class to convert back and forth. These tempalates are not hard to to make.

A second option and possibly a better one depending on your needs is to use the partial class feature of .net 2.0 and implement IXMLSerializable yourself. This really is NOT hard to do, you just need to implement the schema function properly so WSDL has the info to generate the correct classes on the client proxy. So essentially what your doing is,

LLBLGen Entities -> webservices -> client prox -> wsdl generated classes.

This latter didnt work for me, as i wanted plugins on the server and i didnt want two different sets of entities for 3rd party developers to have to work with. So llblgen entities are essentially completely hidden in both clients and server.

Well... 'slow'... that's a bit subjective I think. The objects have to be converted to XML which takes always some performance, and as the xml generated contains state data, it's more verbose than just the entity values.

I think a 3rd option to your list: using webservices as they are intented: pure SOA services with messaging on a high level in the application stack, is the proper approach.

User( Otis/Everyone):

I think I am having a hard time explaining this. The reference.cs file that is created when making a web-reference is not generating information (proxy classes) about the LLBL business object classes. Instead it is putting a using statement making the client reference the LLBL objects to get the EntityCollection class. This reference.cs file should clone the EntityCollection and related objects to be serialized, shouldn’t it? The proxy class is not generating correctly.

Question: Where does the SchemaImporter.dll get called and how does it know it is being called by the wsdl.exe. It is loaded in the GAC and defined in the machine.config, but how does it know how to call it? Nothing references it, right? Is it the namespace defined in the XmlSchemaProvider static method. This is confusing.

User (Answer):

I was using the self-serving templates, before coming acrossed the 3rd party templates, customizing the WriteXML method and then coping the objects into generic object (mirroring the soap message) then pass it over the webserver. I did not like this and only did this because I could not generate a proper proxy. It seems that this is possible if I can get the reference.cs file to generate properly.

The question is why is it not working? Do you have to have LLBL object on both sides of the firewall. You should have too! My client only needs to know the structure because it does not use the LLBL objects. It uses a XML parser to extract the data. My current version is doing this using EntitySpaces, but lacks the maturity of LLBL object for other usages. Do you have any useful links on how SchemaImporterExtension classes are used.

Thanks.

using webservices as they are intented: pure SOA services with messaging on a high level in the application stack

I agree Otis

The reference.cs is not autogenerating the entity collection class becuase IXMLSerializable implementation on it, does not give WSDL any valuable schema info.

Otis:

They were 5 times slower and CPU usage spiked . Its becuase your using reflection in the routines and the XmlSerializer will generate a cached assembly to speed up serialization etc to where llblgen entities cant take advantage of that.

I was able to get them down to about 2 times slower by implementing my own xml output of IXMLSerializable that did not use reflection and output less data.

Answer wrote:

I was able to get them down to about 2 times slower by implementing my own xml output of IXMLSerializable that did not use reflection and output less data.

Could you share that with us?! Would be really great!

User (Answer):

In your environment do you have the LLBL object on both sides of the firewall? If the EntityCollection class is not auto-generated in the proxy and you return this object in the web-service method then your client must have a reference too it. Is this correct? Sorry for not understanding. Then your option is the only way to solve this; To copy the data from the LLBL object into a lightweight object to serialize that has no references to LLBL.

The thing is that I am not getting any object to auto-generate unless I remove the SchemaImport from the project altogether. I only get this in the proxy.

public event GetAllCommunitiesCompletedEventHandler GetAllCommunitiesCompleted;

[System.Web.Services.Protocols.SoapDocumentMethodAttribute(" ... ")]
public EntityCollection GetAllCommunities() 
{

            object[] results = this.Invoke("GetAllCommunities", new object[0]);
            return ((EntityCollection)(results[0]));
}

The problem with this code is that EntityCollection does not exist anywhere. How do I add this to the proxy class.

Thanks for your help, I do appreciate it.

I'm I right in thinking that it might be better not to use LLBL object over WebServices right now for what I need to achive. My client can not understand or reference LLBL at all.

In your environment do you have the LLBL object on both sides of the firewall? If the EntityCollection class is not auto-generated in the proxy and you return this object in the web-service method then your client must have a reference too it. Is this correct?

This is correct, llblgen entities must be on both sides and the client must have a reference to your generated llblgen entities, and to the ORM support libraries...

The thing is that I am not getting any object to auto-generate unless I remove the SchemaImport from the project altogether. I only get this in the proxy.

Its behaving EXACTLY how it should. The whole point of using the schemaimporter extension is so that you can use your custom business objects (llblgen entities in this case) instead of simple dumb objects the WSDL creates for you.

The problem with this code is that EntityCollection does not exist anywhere. How do I add this to the proxy class.

Add a reference to your generated llblgen entities project or dll in the same project as the generated proxy.

'm I right in thinking that it might be better not to use LLBL object over WebServices right now for what I need to achive. My client can not understand or reference LLBL at all.

In this case i would suggest you take the same route i did. Generate your own entities that can easily be passed across web services. My entities for instance reference no other entities so they go across web services just fine. For instance, my order object contains no references to a customer object or a orderdetail object and both tthe customer and orderdetail dont link back to the order at all. Writing a template to output these is very simple.