CSLA .NET discussion

Re: CSLA 4 version 4.3.0 alpha available

sergeyb — Wed, 22 Feb 2012 19:27:21 GMT

Jack,

This process should work just fine. It should work regardless of you using config file or not. It is not intended to be a breaking change. Can you post a sample project that we can use for testing? Did you try what I suggested and capture WCF debug information?

Please let me know more details so that I can look some more into the issue.

Sergey

Re: CSLA 4 version 4.3.0 alpha available

RockfordLhotka — Wed, 22 Feb 2012 03:24:25 GMT

I don't know what is happening. I upgraded all the sample apps without issue...

Maybe it is something to do with compression? Though a couple of the samples use compression too...

Re: CSLA 4 version 4.3.0 alpha available

Jack — Tue, 21 Feb 2012 19:50:41 GMT

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

That is one of my issues – it is a breaking change going from 4.2 to 4.3 for me. I end up with the Remote server not found errors. As I mentioned earlier I tried doing the all or nothing approach, that didn’t work, so I rolled back, finally got things working again. Then I ran the 4.3 installer with the plans of starting another version and it replaced my 4.2 install. The way I noticed is my next rebuild then picked up the 4.3 dll’s and I got the remote server not found errors again.

I had to then do the rollback and uninstall of all CSLA installations (kept complaining about newer version being installed when I ran the MSI’s). I put back 4.2 and got things running again.

I then started a new SVN checkout against 4.3 and after a fruitless afternoon then posted in the forums.

My setup is simple Web project to host the Silverlight Client and then the Silverlight Client talks directly to the WCF web application using the basic compression example in the forums. It is configured with a ServiceReferences.ClientConfig file, not the application startup method.

I haven’t changed that since 3.8 (my production deployment) and had no problems installing all dev builds through 4.2.x

Jack

Re: CSLA 4 version 4.3.0 alpha available

RockfordLhotka — Fri, 17 Feb 2012 21:04:34 GMT

I would recommend going from 4.2 to 4.3 first - which should be entirely seamless.

Then work on configuring the client and server to use the new binary reader/writer.

A Silverlight client must be configured in code as the app starts up. The app server is configured in web.config.

The change log document has Sergey's writeup of the required configuration.

Re: CSLA 4 version 4.3.0 alpha available

Jack — Thu, 16 Feb 2012 23:33:00 GMT

Would you (or someone else) be able to post some basic configuration infomation on how to set that up in the 4.3.x model?

I'm having horrible issues going from 4.2.x using a serviceReferences.clientconfig to the new model.

Thanks

jack

Re: CSLA 4 version 4.3.0 alpha available

tbaldridge — Fri, 10 Feb 2012 21:58:04 GMT

With our app we send a large amount of data across the wire via CSLA. It was our initial performance issues with the serializer that me looking into how to improve the serialization.

I think what should be mentioned though, is that there is a "critical mass" of sorts where this new serializer begins to be a big improvement. In our app, we realized that we were trying to stream 30-70MB of data to the client, and although this compressed down to about 3MB of data after it hit the compressor (SharpZipLib), still, that pressure on the serializer was intense.

With our custom serializer (which is very very close to the new serializer in 4.3.0) we can send massive lists of objects without issue. We can send 70k records to the server in about a 10th of the time of the old serializer.

But back on track...the issue is, the larger your dataset, the more time will be spent in compression, but also the more benefit you will see with compression. The smaller the datasets, the less benefit you'll see with compression, but also the faster the whole processes will be. So for small datasets, why turn compression off? Compression will only take a fraction of the time it takes to send the data down the wire. For larger datasets (and mobile apps) you pretty much have to have compression, or the client will be waiting forever to get the data.

The short version is, we're using the new serializer format, with compression turned on. And and we have no complaints about either.

Re: CSLA 4 version 4.3.0 alpha available

sergeyb — Fri, 10 Feb 2012 13:43:10 GMT

404 is the standard message you get from SL WCF stack as a result of almost any possible error on the server. I think you should put in WCF debugging into your web.config to find out the real issue if you have trouble debugging otherwise.

Just add this section to web.config and run your app to hopefully see the real error:

<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\Traces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>

Re: CSLA 4 version 4.3.0 alpha available

sergeyb — Fri, 10 Feb 2012 13:40:09 GMT

On #4. I think the important thing is the choise that you have. You can decide what is more important to you and your application, CPU/Memory or size of the data over the wire. The choise is entirely yours. My recommendation would be to test all configuration, monitoring memory and CPU usage and then decide. As I mentioned before, you can use compression on top of the new scheme, and will ikley end up still with much better results then before.

Re: CSLA 4 version 4.3.0 alpha available

RockfordLhotka — Thu, 09 Feb 2012 22:50:43 GMT

You probably can't use the clientconfig file when using the new serialization model.

The client-side data portal configures itself either via code or from the config file, but not both. The new serialization model requires code-based configuration.

This is because there is no System.Configuration in Silverlight, so we can't really leverage the clientconfig file ourselves - so we need to choose one or the other.

Re: CSLA 4 version 4.3.0 alpha available

Jack — Thu, 09 Feb 2012 22:10:34 GMT

I am currently using the SL/WCF Data Portal configuration with a ServiceReferences.ClientConfig and the standard Compression implementation. I tried reverting from the Compression Host to the basic default host as well as implementing the steps outlined in the ReleaseNotes but all I ended up with for all my efforts is a RemoteServer NotFound message.

I made a few attempts to model my configuration after the ProjectTracker implementation but no avail.

I then rolled back all my code changes and simply used the 4.3 release and again I had the same issues.

Rolling back to 4.2 and rebuilding finally restored my application

Given the information provided in the release notes should that work with my current setup? Are there 'baby' steps I can make to ensure it works? My setup is Web to host SL app and SL Client talks directly to WCFHost Web app.

Also I recompiled the SL4 project as SL5 before referencing in my application.

Thanks

jack

Re: CSLA 4 version 4.3.0 alpha available

RockfordLhotka — Mon, 06 Feb 2012 22:10:52 GMT

In the alpha release you can use SL 4 or 5.

In the next release the CSLA assemblies will be bound to SL 5, so you'll need to use SL 5 to use that version of 4.3.

Re: CSLA 4 version 4.3.0 alpha available

Jack — Mon, 06 Feb 2012 20:39:07 GMT

To use this with a SL5 application is the recommended approach to leave the libraries as SL4 or to recompile as SL5?

Thanks

jack

Re: CSLA 4 version 4.3.0 alpha available

Tiago Freitas Leal — Mon, 30 Jan 2012 23:05:29 GMT

Looking back at my compression adventures (http://forums.lhotka.net/forums/p/8067/38627.aspx#38627) I found out that the BinaryFormatter byte stream was compressed to 80% of its original size, when using ICSharpCode.SharpZipLib.dll. I guess the Xml byte stream could easily be compressed to 90%. But that's not the point. The point is the compression/decompression overhead.

Usually we need to compress ALL data before starting (compressed) data transmission. Likewise, we need to receive all (compressed) data before starting to decompress. The data is delivered to the application only after it's all decompresssed. This is a nuisance to say the least and only pays back on very low bandwidth lines (like 2 MBps wireless modems); on regular wired networks, compression results on data taking longer to arrive. (I didn't test on a local wireless network) .

I also tried other open source compression algorithm - some GPL and some "use as you wish": SharpZipLib proved to be the one that compresses most but the slowest one.

At the time I was told to use a Sink and an algorithm that can compress the data as it passes by and doesn't have to wait for the whole packet but I didn't try that solution.

Back to the point

1) Can the MobileFormatter start transmission of data before... well, never mind. The MobileFormatter doesn't take care of data transmission, just prepares the packet of data for transmission.

2) Does the MobileFormatter delivers data faster than a compression engine? Yes, of course it does, since it just does a simple data streamline job and doesn't use complex mathematical algorithms.

3) Does the reduced physical transmission time overcome the overhead of the MobileFormatter? I didn't test, but I believe so.

4) Does the reduced physical transmission time overcome the overhead of any compression engine? Referring to my previous tests with Remoting, I don't believe it does.

Re: CSLA 4 version 4.3.0 alpha available

RockfordLhotka — Mon, 30 Jan 2012 15:33:06 GMT

sergeyb:

It does, but you would have to leave your own markers in the stream to let you know how to handle that specific "primitive" type. You would have to do that on both ends: read and write. I think we could open up existing class for that, provided Rocky is cool with that and I have some time to do so along with unit tests to support.

I don't think we'll pursue this. We have a serialization model, and we've now opened the model so it is possible for people to swap in their own reader/writer pairs - so if you want something different you can write it.

In this particular scenario, the value type has to implement two simple methods: OnSetState/OnGetState. Even if we went to all the work to enable a custom serialization type, all that would do is move the code from those two methods into some other location. It wouldn't save any code, it would just rearrange it.

To be honest, I'd much rather spend that dev time optimizing the byte stream and making sure we fully and reliably cover all existing serialization scenarios. Obviously MobileFormatter needs to work in a very reliable manner, so having as many people (you!) test it as possible is important, and having Sergey able to do optimizations and fixes is critical.

Re: CSLA 4 version 4.3.0 alpha available

sergeyb — Fri, 27 Jan 2012 14:29:26 GMT

Even with the new scheme compression will likley shrink the stream some. The key point though is that compression is not free. You are eating up CPU cycles and memory doing it, on both client and server.