I upgraded all CSLA references this weekend from 4.5.10 to 4.5.20 including my Silverlight project and now calls to the DataPortal (from Silverlight) have stopped functioning. The BO is calling client-side methods in Silverlight but the server-side code is never being called. The callback in Silverlight is showing an exception.
System.ServiceModel.CommunicationException: The remote server returned an error: NotFound.
It seems the service endpoint isn't being located but this project has been working for months and I've changed no code or configuration recently other than the nuget update to CSLA and it's dependent packages.
Any ideas?
Just some further info here. This really smells like configuration to me but I've gone over the plumbing several times and I'm not seeing what it could be. I haven't changed anything in Silverlight project other than the update to the new version of CSLA across all projects but I've clearly lost connectivity to the DataPortal. I tried to find "breaking changes" list for 4.5.20 but the change log link goes to github and, either there are no breaking changes or they aren't listed.
My App.xaml contains the following that runs at startup:
Csla.DataPortal.ProxyTypeName = typeof(Csla.DataPortalClient.WcfProxy).AssemblyQualifiedName;
Csla.DataPortalClient.WcfProxy.DefaultEndPoint = "BasicHttpBinding_IWcfPortal";
My ServiceReferences.ClientConfig file in Silverlight contains the endpoint definition for "BasicHttpBinding_IWcfPortal" and if I supply the endpoint address to a new browser while the application is running I get to the service contract page for the DataPortal so I know the endpoint is correctly named and points to a valid service endpoint. The static Get method in my BO makes a call to dataPortal.BeginFetch(criteria) in Silverlight but the DataPortal_Fetch method is never being called in the BO on the .NET side.
Check to make sure the nuget packages in your ASP.NET host project updated correctly.
Most notably, the "CSLA ASP.NET MVC" package won't updated automatically, because we now have two separate packages - one for MVC 3 and another for MVC 4.
The same is true for Entity Framework support - we now have two new packages to support EF 4 and EF 5 respectively.
They look correct. The ASP.NET hosting project for the Silverlight application has only 3 CSLA assemblies referenced, Csla, Csla.Web and Csla.XmlSerializers. I installed them through the package manager console using "install-package CSLA-Core and CSLA-ASP.NET. All thee assemblies show version 4.5.20.0. I went ahead and uninstalled both packages to verify that the three references were removed (they were) and then re-installed them again but still no joy.
In addition, after looking around more, I've made sure my BasicHttpBinding settings in web.config had the max values, e.g. maxBytesPerRead, maxArrayLength, etc. set to the maximum possible value. I'd seen a number of posts suggesting these values set too low can cause the "Not found" exception I'm receiving. I also saw posts where you'd suggested setting up data compression which I haven't done but I do not believe this is the issue. The app has been working for months without it and the first call to the DataPortal that is failing is the login which sends and receives very little data.
Adding serviceModel section from web.config and ServiceReferences.ClientConfig from the Silverlight app in the hopes that someone can spot an issue. I hadn't changed any of this since I first migrated to CLSA 4 a few months ago but I'm wondering if 4.5.20.0 had breaking changes that made some setting here erroneous.
From web.conf in ASP.NET Silverlight hosting project:
<system.serviceModel> <services> <service behaviorConfiguration="WcfPortalBehavior" name="Csla.Server.Hosts.Mobile.WcfPortal"> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWcfPortal" contract="Csla.Server.Hosts.Mobile.IWcfPortal"> <identity> <dns value="localhost" /> </identity> </endpoint> </service> </services> <behaviors> <serviceBehaviors> <behavior name="WcfPortalBehavior"> <serviceMetadata httpGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="true" /> </behavior> </serviceBehaviors> </behaviors> <bindings> <basicHttpBinding> <binding name="BasicHttpBinding_IWcfPortal" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" receiveTimeout="00:10:00" sendTimeout="00:10:00" openTimeout="00:10:00" closeTimeout="00:10:00"> <readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxDepth="1000" /> </binding> </basicHttpBinding> </bindings> </system.serviceModel>
From ServiceReferences.ClientConfig:
<system.serviceModel> <bindings> <basicHttpBinding> <binding name="BasicHttpBinding_IWcfPortal" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" receiveTimeout="00:10:00" sendTimeout="00:10:00"> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="http://localhost:49999/WcfPortal.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWcfPortal" contract="WcfPortal.IWcfPortal" name="BasicHttpBinding_IWcfPortal" /> </client> </system.serviceModel>
End
Hi Dane,
It looks like I had the same problem.
My configurations on the ServiceReferences.ClientConfig file were useless. So I changed App.xaml.cs and added
private void Application_Startup(object sender, StartupEventArgs e) { Csla.DataPortal.ProxyTypeName = typeof(Csla.DataPortalClient.WcfProxy).AssemblyQualifiedName; Csla.DataPortalClient.WcfProxy.DefaultUrl = "http://localhost:<PORT>/SlPortal.svc"; }
Of course, on the server side I had to change everything that read Hosts.Silverlight.WcfPortal to Hosts.Mobile.WcfPortal.
After all the corrections, Silverlight runs lightning fast as it did on 4.3.13
Tiago:
Thank you for the suggestion. Unfortunately that didn't change anything. I had already updated all the namespacing from "Silverlight" to "Mobile" when I updated to 4.5.10 a couple months ago. Everything had been working since then right up until I updated to 4.5.20 this last weekend. Very frustrating.
Even though that didn't work for me I really appreciate your time in trying to help. Thanks again.
I uninstalled the nuget CSLA-Silverlight package and re-installed version 4.5.10 (the version I was using prior to this problem). It appears there is definitely some issue with version 4.5.20. The server-side code of my BO classes still do not run (never gets to DataPortal_Fetch) but the exception I get now is different.
NullReferenceException
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Csla.DataPortal`1.<BeginFetch>d__1e.MoveNext()
The difference now is that the Csla.DataPortal is clearly being called instead of the Not Found I was previously receiving which indicated the BO was unable to locate the WCF service endpoint. I suspect this new exception has to do with the fact that I only rolled the Silverlight application's version of CSLA back and did not roll back CSLA versions for server-side code but I'd rather not have to roll everything back to confirm that. The fact that I was getting a service location failure with 4.5.20 and 4.5.10 at least gets to the DataPortal suggest there's an issue with the CSLA Silverlight package 4.5.20.
Tonight I uninstalled all CSLA packages in my solution. That was no easy chore. I found that I had both 4.5.10 and 4.5.20 packages installed through the solution and in attempting to remove these I was actually receiving errors stating CSLA 4.5.10 could not be removed because it was a dependency of CSLA 4.5.10. I suspect this had to due with the shared .NET/Silverlight code but it was still painful to find the proper order of removal. In the end, however, I did.
After the CSLA "scrape" I re-installed all needed CSLA packages throughout my solution. When I re-ran my Silverlight project I still received the original "Not Found" error. My BO Silverlight code is simply not connecting to the WCF DataPortal correctly.
A short time ago I began work an ASP.NET MVC UI for my application. In that project I'm finding no corresponding issues. This appears to be an issue exclusive to Silverlight.
During tonight's clean and re-install process I again had to accept installing an "RC" package. Afterwards I see both packages "Async for .NET Framework 4, Silverlight 4 and 5..." and BCL Portability Pack for .NET Framework 4, Silverlight 4 and 5..." are installed as "Prerelease".
Since I'm out of ideas for resolving my issue and this forum thread has borne no fruit I'm going to move forward on the working assumption that my issue here is arising from some issue encompassed in that word "Prerelease" and that a fix will someday be forthcoming.
I just returned from traveling and am slowly catching up on emails and forum posts, etc.
Is your solution a .NET 4 and SL4 solution, or a .NET 4.5 and SL5 solution?
.NET 4.5 / Silverlight 5
I am not sure what to suggest at this point then.
I have solutions with .NET 4.5 and SL5 and 4.5.20 working just fine, so I am pretty confident that this scenario operates as expected.
Have you right-clicked on the _solution_ and managed the nuget packages from that level? That is an easy way to find any old versions of packages that might be attached to one of the projects.
Yes. I'd originally used the Package Manager Console to add/update all the packages but last weekend I used the Manage nuget Packages UI accessed from the solution, stripped out all packages and re-added everything from the ground up. No change.
When the application is running I can provide the browser with the endpoint address specified in the ServiceReferences.ClientConfig and get to the WSDL presented by the WCF DataPortal so I know it's active but it appears the Silverlight application is not finding that endpoint.
Is it possible that there's some client access policy or cross domain issue going on all of a sudden? I've never had to include a clientaccesspolicy.xml or crossdomain.xml file for this project before but I've seen this exact behavior occur under Silverlight in situations where they were needed but non-existent.
Also, can you point me towards the latest sample project that you referenced, i.e. .NET 4.5, Silverlight 5 and CSLA 4.5.20? Maybe I can find something by performing a comparison.
The SimpleNTier project is (to my knowledge) completely up to date on all versions.
I found the SimpleNTier with 4.5.20 and have the Silverlight UI running. It appears to be pulling data so I've started looking at differences.
1. SimpleNTier has no ASP.NET host project. I set the SilverlightUI project as the start in project and it appears to be connecting to the WcfHost correctly.
2. SilverlightUI App.xaml.cs sets Csla.ApplicationContext.DataPortalProxy and Csla.ApplicationContext.DataPortalUrlString and has an empty ServiceReferences.ClientConfig. My project was setting Csla.DataPortal.ProxyTypeName and using the config file for endpoint. I tried changing it to use the two ApplicationContext settings and emptying the config file as in the SilverlightUI project but still no change.
3. The SimpleNTier application is using task based async. I haven't converted to that yet and am still using callbacks.
4. The WcfHost project in SimpleNTier contains a clientaccesspolicy.xml file. I've never needed one before but I went ahead and added it to my ASP.NET hosting project. No change.
5. References to CSLA assemblies in the SimpleNTier application are relative path while mine were all done through nuget. I've gone through all the references numerous times and everything is set to CSLA 4.5.20 assemblies and looks correct.
6. SilverlightUI specifies SlPortal.svc as the endpoint and the WcfHost application has both SlPortal.svc and WcfPortal.svc. I have only a WcfPortal.svc though the service specified it the same as in the SlPortal.svc, i.e. Csla.Server.Hosts.Mobile.WcfPortal. It looks like the WcfHost's WcfPortal.svc is for one of the other .NET projects.
7. SimpleNTier appears to be using Factory Invoke data access model while I use the Encapsulated Invoke method. The data access is, however, working as expected in my MVC project.
None of these seem like likely candidates but I'm unable at this point to find other differences. The fact that the SimpleNTier app is accessing the DataPortal and mine isn't tells me there is some difference but I'm quickly running out of ideas as to what it could be. My next step may be to remove all nuget references and roll back to relative path. Having just recently migrated the entire project to nuget package management this thrills me not at all but I'm not sure what else to try.
More:
1. I updated the method I've been using as a quick test to be Task based async. No change.
2. I removed all CSLA nuget packages and used relative path references to assemblies (the same ones I found in SimpleNTier). No change.
3. I changed the URL in the App.xaml file to something other than what the svc endpoint is actually being hosted on. The error changed to indicate the endpoint could not be found which tells me the Silverlight app is indeed contacting the host but the host is failing to process the request.
Try using fiddler to watch the network traffic and see if the request is getting to the server, and how the server is responding.
I was just finishing using WCF trace logging when you sent the last reply. In the trace log I found and exception was being caught at the service level. Deep in the stack trace was this:
Csla.ApplicationContext..cctor()</StackTrace><ExceptionString>System.IO.FileLoadException: Could not load file or assembly 'Csla, Version=4.5.10.0, Culture=neutral, PublicKeyToken=93be5fdc093e4c30' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'Csla, Version=4.5.10.0, Culture=neutral, PublicKeyToken=93be5fdc093e4c30'
I went back and checked all reference again. All looked good at 4.5.20. I cleaned the solution (for about the 50th time) and re-ran. Same issue. I then did a findstr on the solution directory on the text "4.5.10" and low and behold there were two assemblies, Csla.Windows.dll and Csla.Xml.dll sitting in the bin sub-directory of the ASP.NET hosting project that "Clean Solution" was not deleting. I closed the solution, manually cleaned it by deleting all obj and bin folders, re-opened it and re-ran. BINGO! Working DataPortal!
I knew it was working in 4.5.10. Previously referenced assemblies were not removed by deleting the reference and cleaning the solution and the hosting project was loading them as a matter of course which, since they were dependent on previous versions of CLSA were of course causing dependency issues.
Thanks for the help. Maybe I'll sleep better tonight :-)
I am having the same problem. I think the problem is in Silverlight ApplicationContext.DataPortalProxy is null or empty and is being set to "Local". I see this code changed from version 4.3.... I am currently trying to figure out what it should be set to.
See code from version 4.5.20 below. ApplicationContext.cs
public static string DataPortalProxy { get { #if !SILVERLIGHT && !NETFX_CORE if (string.IsNullOrEmpty(_dataPortalProxy)) _dataPortalProxy = ConfigurationManager.AppSettings["CslaDataPortalProxy"]; #endif if (string.IsNullOrEmpty(_dataPortalProxy)) _dataPortalProxy = "Local"; return _dataPortalProxy; } set { _dataPortalProxy = value; DataPortal.ResetProxyType(); } }
I think that's a different issue (and one I ran into previously as well here http://forums.lhotka.net/forums/p/11675/54141.aspx#54141 ). The "Local" DataPortal concept isn't valid in CSLA 4.5 any longer.
I found that PagedLlist had the same problem as my own project. So I tried to fix the PagedList Project.
After going through the steps of upgrading the project to 4.5 .Net ...
I added
Csla.ApplicationContext.DataPortalProxy = typeof(Csla.DataPortalClient.WcfProxy).AssemblyQualifiedName; Csla.ApplicationContext.DataPortalUrlString = http://localhost:29082/WcfPortal.svc;
To the Application_Startup method in the App.xaml.cs.
That fixed the PagedList demo project.
For me anyways hard coding the URL and DataPortalProxy made the problem go away. But I think there is problem with Silverlight ServiceReferences.ClientConfig configurations. I have not spent much time on this yet.
A user above had the same issue but I'm using ServiceReferences.ClientConfig to hold my service information and it's working good again now that I removed the old assemblies that Clean Solution didn't delete.
Copyright (c) Marimer LLC