Here is the code in my Factory method:
var dp = new DataPortal<PFrame>();
dp.FetchCompleted += callback;
dp.BeginFetch(new SingleCriteria<PFrame, Int32>(PersonKey));
Here is the DataPortal_Fetch:
private void DataPortal_Fetch(SingleCriteria<PFrame, Int32> criteria)
{
}
For some reason the call does not even make it to the first line of the Fetch method.
I walked thru the code upto the line "proxy.FetchAsync(request);' in WcfProxy.cs. The request parameter at this point has:
ClientCulture, ClientCultureField, ClientUICulture, ClientUICultureField are null
TypeName and TypeNameField are also null
All other fields have data
In proxy_FetchCompleted, the response comes back with error.
The final message in error window is:
Code: 4004
Category: ManagedRuntimeError
Message: System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid. Check InnerException for exception details. ---> System.ServiceModel.CommunicationException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound.
at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
at System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)
--- End of inner exception stack trace ---
at System.Net.Browser.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.Browser.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)
--- End of inner exception stack trace ---
at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
at Csla.WcfPortal.WcfPortalClient.WcfPortalClientChannel.EndCreate(IAsyncResult result)
at Csla.WcfPortal.WcfPortalClient.Csla.WcfPortal.IWcfPortal.EndCreate(IAsyncResult result)
at Csla.WcfPortal.WcfPortalClient.OnEndCreate(IAsyncResult result)
at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)
--- End of inner exception stack trace ---
at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()
at Csla.WcfPortal.CreateCompletedEventArgs.get_Result()
at Csla.DataPortalClient.WcfProxy`1.proxy_CreateCompleted(Object sender, CreateCompletedEventArgs e)
at Csla.WcfPortal.WcfPortalClient.OnCreateCompleted(Object state)
') occurred in iexplore.exe [6220].
I am not sure where to go from here.
Jav
Yeah, this is one of those obscure WCF exceptions. It basically means that WCF, on the server, couldn't find something - probably whatever assembly contains your host/portal class (and that's probably Csla.dll unless you are using a custom compressed proxy or something).
But it might be finding Csla.dll and not finding the type inside the assembly.
So odds are that either Csla.dll isn't in the bin directory, or that you have a config issue. The config issue is the most likely problem. Compare your web.config system.serviceModel section to a known-to-be-working server web.config and see what's different.
Rocky,
I am a little confused about the contract value in the endpoint in ClientConfig file. for example, the following is from SimpleApp:
<client>
<endpoint address="http://localhost:1993/WcfPortal.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWcfPortal"
contract="WcfPortal.IWcfPortal" name="BasicHttpBinding_IWcfPortal" />
</client>
This was also the gist of suggestion made by the user from Netherlands (I am sorry, I cannot recall his name). The reason I ask is that that is what I had in my Csla4.0 project, and now I am wondering if that may be the problem. The reason I said 'had', instead of 'have', is because I set aside the 4.0 project this morning and went back to the last 3.8.4 version. I am now making a second attempt, this time trying to be more methodical and cotinuously testing after change.
I have now come to the point where I have the 3.8.4 project working in .Net 4 and SL 4. But the interesting thing is that my endpoint is:
contract="Csla.WcfPortal.IWcfPortal" name="BasicHttpBinding_IWcfPortal" />
and everything is working just fine. I thought? the whole point of that modification was to run 3.8.4 projects with SL 4. In any case this time, I have already made all DataPortal.Deletes generic, they were the only non generics. All PropertyInfo's are public. All Criteria classes are BusinessBase, and all validation stuff is simply commented out. Hopefully this time the sudden explosion of errors would be more easily managed so I can start testing earlier in the process.
I am using Csla provided compression. It is also possible that I was not referencing the right Csla dll in my different projects. Well! It's once more with feeling.
Thanks for you help.
Jav
Well, one thing is clear, this is the correct form
contract="WcfPortal.IWcfPortal" name="BasicHttpBinding_IWcfPortal" />
I am getting the same exact error.
May be the Csla Libraries in different projects are not right.
My three Business Libraries reference the Silverlight\Csla.dll in the Client Projects, and Server\Csla dll in the Server Projects.
Compression projects do the same in the Client and Server projects.
Silverlight project references Silverlight\Csla.dll and Silverlight\Csla.Xaml.dll
Web project references Server\Csla and Server\Csla.Web
I have a couple of code support projects that reference Server\Csla.
While typing all this I have realized that I do not reference anything from the Client folder.
Perhaps the next option is to create a totally new Solution using VS10, SL4, Net4, Csla4; and then first make sure the Client side can talk to Server side.
Can't say that the thought is pleasant in any way shape or form. But a person's gotta do what a person's gotta do. But I have to admit, I would love for someone to stop me. Call me stupid if you want to - I won't mind. At All.
Jav
As I am trying to dissect out this problem by starting with a minimal project and building up, I am noticing a problem.
Right now I have a simple SL page which used CslaDataProvider which make a call withoout any parameters for a small set of values from the database. When I run it without compression, I see the data being displayed properly. When I do it through compression, I get this error:
---------------------------
=Error
---------------------------
An Error Has Occured
ICSharpCode.SharpZipLib.SharpZipBaseException: Header checksum illegal
at ICSharpCode.SharpZipLib.Zip.Compression.Inflater.DecodeHeader()
at ICSharpCode.SharpZipLib.Zip.Compression.Inflater.Decode()
at ICSharpCode.SharpZipLib.Zip.Compression.Inflater.Inflate(Byte[] buffer, Int32 offset, Int32 count)
at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at CompressionLib.Compression.CompressionUtility.ReadFullStream(Stream stream) in E:\MyDocuments\Visual Studio 2010\Projects\ESilverlight\CompressionServer\CompressionUtility.cs:line 51
at CompressionLib.Compression.CompressionUtility.Decompress(Byte[] byteInput) in E:\MyDocuments\Visual Studio 2010\Projects\ESilverlight\CompressionServer\CompressionUtility.cs:line 38
at CompressionLib.Compression.CompressedHost.ConvertRequest(CriteriaRequest request) in E:\MyDocuments\Visual Studio 2010\Projects\ESilverlight\CompressionServer\CompressedHost.cs:line 12
at Csla.Server.Hosts.Silverlight.WcfPortal.Fetch(CriteriaRequest request) in E:\MyDocuments\Visual Studio 2010\Projects\Csla4.0\Source\Csla\Server\Hosts\Silverlight\WcfPortal.cs:line 87
The same Compression projects were working fine right through VS10, Net4, SL4, Csla3.8.4 handling significant amounts of data back and forth. I am not sure if this represents the root of my problem, or merely a secondary issue to crop up due to something new.
Jav
That wasn't it. That was because I had forgotten to modify the App.xaml for compression.
But I do see a glimmer of light at the end of the tunnel.
It took hours of work and a lot of fits and starts with new projects, but I am pretty sure I know what is causing the problem.
It is the old crossdomain / clientaccesspolicy issue again. Surprising thing is that this time it is not going to VS10 or to .Net 4.0, or to SL 4. None of those had an issue with my crossdomain.xml. But as soon as I go to Csla 4, everything falls apart.
Here is what happened. See, I started creating my minimal new projects in VS2008, SL 3 because that seemed logical. Even though the SL part was no more than a CslaDataProvider and simple Server and Client projects patterned after the SimpleApp demo with DataPortal but no DB access. It worked like a charm, and would work fine even after I converted to VS10, SL4 But I would run into problems as soon as I plugged in Csla4. I would log in to the Default page, and then go to SL page and like clockwork the error would pop up even with that simple client to server DataPortal access.
Only wanting to cut short the process from start to the final error, I decided to create the SL project in VS2010, SL 4. Suddenly everything seemed to work after I changed to Csla 4. I didn't even notice that there was no Default page. I started to add my Busines libraries, expecting the shoe to drop at any moment. My test was still the minimal Client-Server arrangment, but it kept working. I then imported all the SL code, and still no problem. I could now plug in the ViewModels with fictious parameters and the whole SL stuff was loading perfectly from the DB.
Feeling pretty good, turned my attention to the Web project. Where is the Default page I thought. Well no problem I'll just drag the Default and Login stuff from the old project. All I needed was one final test. I was done for the day. Press F5, select a person from the list, click the button to go to SL page, lean back in the chair, rest the old neck and shoulders.
And then Bamm. "Not so Fast, Fella", said the big ol' error message. "Not Found, Not Found, everywhere", I even heard the computer say, Na, Na, Nana, Na". I can't share what I said in response. I wasted no time to undo what I had just done, quickly removing the Default and Login pages. Then I sat there for a few seconds with my finger on F5. I think that pause and the little prayer is what did the trick. Of course the removal of Default and Login pages helped too. My SL page appeared in full glory once more. No nasty errors.
Here is what I have in my crossdomain.xml:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
and in my clientaccesspolicy.xml
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
So now what do we do? The answer to that is way, way above my pay grade. I can't believe that many others won't have the same problem.
Jav
If you need the cross-domain policy file, that's a sure sign you aren't running the SL app from the same web app as the one where the data portal is hosted. Probably your SL project itself is the startup project - in which case VS automatically creates a temporary web project (without you seeing it) to host the SL app for debugging.
Rocky, I discovered that I need the crossdomain file months ago, and every thing was working great. But upgrading to Csla 4.0 has made that crossdomain file "ineffective". I have to run the SL app from within an ASP.net App where the user can log in and perform a lot of other functions in plain old Asp.net forms.
The questions that I have now are: 1. Why does moving to Csla 4 topples the apple cart, so to speak? 2. What steps can I take to get my project functioning. 3. Is there some change I can make to the crossdomain file that will make it work.
Do I have to just go back to Csla 3.8.4 and stop making fuss 
?
Jav
I've been skimming through the posts, and there is a piece which isn't clear to me. I've gathered you're using SL4, and that you upgraded Csla from 3.8. Did you at the same time from from SL 3 to SL4? Sorry, I realize you most likely already thought of this, but through I'd throw it out on the slim chance you hadn't. :-)
Phew! Finally got it working - and no it wasn't Csla 4.0 it was configuration issue (funny, it seems like I heard that somewhere). But I'll say one thing - It's a jungle out there. These are some notes I like to share hopefully to help someone else.
With Three Business Libraries and an SL project, I only have four ServiceReferences.ClientConfig files. In VS08, SL3, Net3.5, I simply copied one properly created .ClientConfig file in each of the four places without messing with Service References in each project; and it worked fine. Not anymore, or so it seems. I checked my ClientConfigs over and over again. Couldn't find anything wrong - but the project wouldn't work.
So I decided to use the Service References item to create them. I am sure for a normal web service this process will work fine, but trying to create it for WcfPortal, invariably will mess everything up. You then have to go clean it all up manually, especially the Contract and the Name of the Reference. I created Service References and made sure my ClientConfigs weren't screwed up . I clicked in each service reference and looked it up in the object browser, and everything looked fine. But none of that helped.
Having nothing else to do, I almost aimlessly right clicked on the ServiceReference (Not the .ClientConfig file, but the reference). Of the three items in that drop down, I had already used "Update Service Reference" and "View in Object Browser", so I selected "Configure Service Reference". The dialog opened, and there didn't appear to be anything relevant. As I was about to close the dialog when I glanced at the Address field and almost fell out of my chair. Folks, the address in the field was that of the very original address allocated to the Web Project (localhost:1816) when the Solution was created. Since creating the Solution I had transfered the web over to IIS. It was lucky that I had clicked on the ClientConfig in the SL project, because the other three references were just fine.
Moral: When checking your Web Addresses in the ClientConfig files, don't forget to look at the Address in the Service Reference by clicking Configure Service References.
Jav
I have no idea what you are talking about with adding service references and so forth.
If you are using the data portal, the service references are already set up, you just need to add configuration to your main SL app project so the client can find the server.
Of course if you've created your own custom proxy/host that doesn't use the existing data portal interface (you didn't subclass the CSLA proxy/host classes) then you absolutely would need to do some service reference work - but I don't think that's what you did?
Somehow I think things have gone off the rails for you, and the answer is almost certainly much simpler than what it sounds like you are doing.
Copyright (c) Marimer LLC