For some days I have been looking at LLBLGen Pro. It is very promising and I want to buy it, but there is one thing I have to have cleared first. How can one use LLBL with SCSF/CAB and using LLBL with a tcp-remoting connection? How would you implement the tcp-connection service? I have tried to use: RootWorkItem.Services.Add<SomeInterface>(??) but that want go. Is there another way of doing this without to have to reference the remotinghelper dll in every module?

Best regards

Did you receive my email reply ? If not I'll quote it here below

The client receiving the entity objects has to know the types of these objects, so has to reference the generated code which contains the entity classes (dbgeneric project)

If you don't have a pre-defined service contract nor a channel registration, .NET will generate its own proxy classes and that's not going to work.

We're not familiar with SCSD/CAB, though if you define an interface which is implemented by the service and store that in a separate assembly, you can develop the client without referencing the service. See the remoting example on our website for details.

Otis wrote:

Did you receive my email reply ? If not I'll quote it here below

The client receiving the entity objects has to know the types of these objects, so has to reference the generated code which contains the entity classes (dbgeneric project)

If you don't have a pre-defined service contract nor a channel registration, .NET will generate its own proxy classes and that's not going to work.

We're not familiar with SCSD/CAB, though if you define an interface which is implemented by the service and store that in a separate assembly, you can develop the client without referencing the service. See the remoting example on our website for details.

Hi Otis

I got your email - very quick response thank you. I have studied the examples and I know that the dll's from the BBLBGen must be referenced at the client side. But my problem is the connection. In SCSF you try to have everything in loose coupling manner. That will say, it does not matter what kind of connection you use - wcf, wse?, .Net.remoting or what ever, it should not affect your programs if you change from one to the other. That is you dont have to compile all modules again. I hope I have made my problem clear enough.

Thanks

Ok, though I think that won't work, because MS solved that with a route through WSDL.exe, if I'm not mistsaken. The thing is that it tries to generate proxy classes for the transportation, which won't work, as the real classes have to be transported (I know the data is transported, but when proxy classes are used, our own code to make sure the data is PROPERLY serialized is bypassed).

For WCF, a servicecontract is required to make things work (as you've to define known types, otherwise MS' code will generate proxy classes for itself.. ) and remoting requires a channel so proper binaryformatter support is guaranteed, as otherwise the data is serialized to XML which is then transported over remoting channels, if I'm not mistaken. (way too slow compared to our fast remoting layer)

Hi,

To keep up with the loose coupling rule in SCSF/CAB I wanted to use RootWorkItem.Services.Add<SomeInterface>(someservice) ,where SomeInterface is the LLBLGen Pro generated interface, to keep the DALServic global to all modules. This wont go as Otis explained.

Now I have tried another road. I would be very happy if those of you who use LLBLGen with SCSF to comment on this if you use another and better way to do this.

1. Make an assembly where I open the channel, tcpchannel. In this assembly is one method who returns the Dalservice.
2. This assemply is referenced only ones in the SCSF-project. (F.eks in Shell or login form) and add the service to RootWorkItem. See further down.
3. Make a service-module, name it RemoteService and one class:

public class RemoteDALService { private IAgnesService _dalservice;

    public IAgnesService  Dalservice
    {
        get { return _dalservice; }
        set { _dalservice = value; }
    }
}

(IAgnesService is the LLBLGen generated interface)

1. In the Shell I add this service to the RootWorkItem:

      RemoteServiceHelper.Services.RemoteService rc = new     Zeuss.RemoteServiceHelper.Services.RemoteService();
       rc.TcpService();
       IAgnesService DalService = rc.DalServices();
       RemoteDALService context = RootWorkItem.Services.AddNew<RemoteDALService>();
       context.Dalservice=DalService;
   

2. In every "Some"-viewpresenter I inject this service like that:

private RemoteDALService _remoteService;

    [InjectionConstructor]
    public Some_ViewPresenter
        (
        [ServiceDependency] RemoteDALService remoteService
        )
    {
        _remoteService = remoteService;
    }

Now I have access to Dalservice in all modules.

What I have seen and tested of LLBLGen Pro, I can say that SCSF and LLPLGen go together beautifully.

Thanks

What I have seen and tested of LLBLGen Pro, I can say that SCSF and LLPLGen go together beautifully

Thanks for the feedback. I hope somone using SCSF can give you his/her comments too. Anyway this would be useful for anyone going into the same route.

What exactly do you mean with 'LLBLGen generated interface' ? The proxy classes ?

Otis wrote:

What exactly do you mean with 'LLBLGen generated interface' ? The proxy classes ?

Sorry, this interface is not generated by BBLBGen, but you make it as an interface to the host-services. (Hope this is right!! Do you call this a proxy??).

Thanks

Ah ok makes sense

hehhe, BBLBGen I know the name is hard to pronounce, but also hard to type, I didn't know...

Otis wrote:

Ah ok makes sense

hehhe, BBLBGen I know the name is hard to pronounce, but also hard to type, I didn't know...

Ok, you know B is before L so it is easy to make mistake in the beginning. Will try to do it right next time, "LLBLGen Pro" shall it be. (What does it stands for?)

LLBLGen = Low Level Business Layer generator if I'm not mistaken. I have to think about what it stands for in order to spell it correctly.

But what would BBLB stands for then? Perhaps the arcade game "Bubble Bobble"...

hehe bubble bobble

Indeed lower level business logic layer generator.

Hi, for some weeks we have been using LLBLGen Pro with Cab/SCSF (For the firt time). It has been fantastic and easy. LLBLGen is like a dream of your own. The program we are making are relatively big and complex. Until now we have been using it in our working environment, but now is the time to put it public. We are using remoting channel, tcp. Now the question is how robust is it? We will find out soon! (Or is it something we have to be careful about?) But my question is, have you tried to use "FireDaemon Pro" to keep your host.exe up and running on a server? Or do you make a windows service to do that?

I usually use Windows Service or host in IIS.