Hi Rocky
We have designed our WPF application using CSLA 4.5.31 using the MobileProxy available for target framework .NET 4.0 based on knowing it will be used on XP machines that does not support .NET 4.5.
During testing this all tested fine until actual testing was done on a XP machine. We then tested this on a Windows 7 machine and works until we uninstall .NET 4.5 where after we get the same error.
We have gone so far to change ProjectTracker's target framework to .NET 4.0 with the same results and hopeful testing done with the latest CSLA version 4.5.40 also had no luck.
We get the following error:
System.Runtime.Serialization.InvalidDataContractException: Type 'System.Threading.Tasks.Task`1[Csla.WcfPortal.WcfResponse]' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types.
at Csla.DataPortal`1.Fetch(Type objectType, Object criteria)
at Csla.DataPortal`1.Fetch(Object criteria)
at Csla.DataPortal.Fetch[T](Object criteria)
at ProjectTracker.Library.Security.PTIdentity.GetPTIdentity(String username, String password) in c:\Projects\CSLA4540\Samples\NET\cs\ProjectTracker\ProjectTracker.Library\Security\PTIdentity.cs:
There was a related issue http://forums.lhotka.net/forums/p/11585/53704.aspx#53704 but it was related to WCF and it seemed that the problem was resolved in the framework rather than how it was implemented.
Your help and guidance regarding this issue will greatly be appreciated.
Thank you
Jannie
Yes, you are correct. This is a bug that became reintroduced at some point in May 2013.
The ServiceReference for WcfPortal in Csla.NET4 is generated with Task<T> contract for .NET 4.5.
Affected versions is: V4.5.40, V4.5.32-Beta and V4.5.31-Beta
See: https://github.com/MarimerLLC/csla/issues/207
(To be fixed and released in Csla.4.5.50 or earlier if Rocky decides to do so)
Our current plan is a .50 fix, since that version should be out in a couple weeks.
Hi Rocky
Any idea when this release is going out. We have been delaying or rollout due to this.
Is there any way we can compile the fix on our side as a temporary measure until this release.
Jannie
Hi,
Fix is checked in and you can download the latest source from GitHub and build the assemblies yourself.
Goto https://github.com/MarimerLLC/csla and select "Download ZIP" button.
Hi Jonny,
Any idea when the new version will be up on Nuget?
Thanks
I plan to do a final prerelease of the latest code this weekend. That'll put the code into NuGet as a prerelease.
Hi Rocky
We have tested this release and works fine on Windows 7 but the following error occurs when running the application on XP.
The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.
1) The maximum array length quota (16384) has been exceeded while reading XML data. This quota may be increased by changing the MaxArrayLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 78647.
There was an error deserializing the object of type Csla.WcfPortal.WcfResponse. The maximum array length quota (16384) has been exceeded while reading XML data. This quota may be increased by changing the MaxArrayLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 78647.
The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://ws.lhotka.net/WcfDataPortal:FetchResult. The InnerException message was 'There was an error deserializing the object of type Csla.WcfPortal.WcfResponse. The maximum array length quota (16384) has been exceeded while reading XML data. This quota may be increased by changing the MaxArrayLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 78647.'. Please see InnerException for more details.
The app.config is exactly the same on both OS's.
We are not sure if the config has to be changed for XP.
Our web.config looks as follows:
<?xml version="1.0" encoding="utf-8"?>
<!--
For more information on how to configure your ASP.NET application, please visit
http://go.microsoft.com/fwlink/?LinkId=169433
-->
<configuration>
<appSettings>
<add key="CslaAuthentication" value="Csla" />
</appSettings>
<system.serviceModel>
<services>
<service name="Csla.Server.Hosts.WcfPortal" behaviorConfiguration="returnFaults">
<endpoint binding="wsHttpBinding" bindingConfiguration="wsHttpBinding_IWcfPortal" contract="Csla.Server.Hosts.IWcfPortal" />
</service>
<service name="Csla.Server.Hosts.Mobile.WcfPortal" behaviorConfiguration="returnFaults">
<endpoint binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IWcfPortal" contract="Csla.Server.Hosts.Mobile.IWcfPortal" />
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="basicHttpBinding_IWcfPortal" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647" maxBufferSize="2147483647">
<readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647" />
</binding>
</basicHttpBinding>
<wsHttpBinding>
<binding name="wsHttpBinding_IWcfPortal" maxReceivedMessageSize="2147483647">
<readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647" />
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="returnFaults">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
<connectionStrings>
</connectionStrings>
<system.web>
<authentication mode="Forms" />
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="System.Net, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="PresentationCore, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
</assemblies>
</compilation>
<pages controlRenderingCompatibilityVersion="4.0" />
</system.web>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
and app.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>
<appSettings>
<add key="CslaAuthentication" value="Csla" />
<add key="CslaDataPortalProxy" value="Csla.DataPortalClient.MobileProxy, Csla" />
<add key="CslaDataPortalUrl" value="http://jester/DionysusHost/SlPortal.svc" />
</appSettings>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.IO" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.6.6.0" newVersion="2.6.6.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.6.6.0" newVersion="2.6.6.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.6.6.0" newVersion="2.6.6.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Csla" publicKeyToken="93be5fdc093e4c30" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.5.40.0" newVersion="4.5.40.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.6.6.0" newVersion="2.6.6.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.6.6.0" newVersion="2.6.6.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
<providers>
<provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
</providers>
</entityFramework>
</configuration>
Thanks
I am afraid I haven't had an XP machine in years, but it wouldn't surprise me if WCF acts somewhat differently on XP.
I know this is probably small consolation, but we're just 3 months from XP going entirely and completely off support. I pity anyone using any XP machines come May - at least if those machines are in any way connected to a network.
Last week there were some stats that came out, and almost 30% of machines are still running XP. The virus/malware people are going to have a ton of fun attacking and succeeding in taking over or disrupting XP machines worldwide...
Back to your question though, I'd suggest you check MSDN to see if Microsoft has any info on running WCF on XP and if there are limitations around doing that.
Hi Rocky
We investigated a bit further and replicated the same error on Windows 7 running .NET 4, so it seems to be a .NET 4 issue and not a XP error like I indicated in my previous post.
This error occurs when a large amount of data is retrieved. The application login call to the mobileproxy portal runs fine but the next step is to retrieve a large list and fails at that stage with the above mentioned error.
Thanks
Jannie
Copyright (c) Marimer LLC