Quantcast
Channel: Open RIA Services
Viewing all 124 articles
Browse latest View live
↧

Closed Unassigned: HttpContext with WPF [95]

July 31, 2016, 1:30 am
$
0
0
Hello,
Our company is migrating an application from Silverlight 5.0 to WPF 4.5. In the process of migrating we have implemented Open RIA Services . And everything works great with Silverlight. However, when using RIA services with WPF we lose HttpContext.Current settings from call to call. Is there a way to persist HttpContext in WPF for the “session”, similar to what happens with Silverlight? (i.e, can we use HttpContext.Current to save settings from call to call?)

Comments: Hi. In OpenRiaServices 4.4 the WPF client does not persist cookies so session data will not be available across requests. Please try out the 4.5.0-beta3 prerelease (see https://openriaservices.codeplex.com/releases/view/619745). I will close this issue for now, feel free to open it if it does not work with the last prerelease.
↧
Search

Source code checked in, #6f0fbf313f5114cc5d692838f752c3afe61fed16

August 20, 2016, 1:55 am
$
0
0
Update nuget packages to 4.5.0-rc1
↧
↧

Edited Issue: Slow first call to a service [94]

August 20, 2016, 5:11 am
$
0
0
The first call to a ria service is slow if they are many assemblies without PublicKeyToken (5s on my project).

The problem is the try/catch in OpenRiaServices.DomainServices.TypeUtility.IsSystemAssembly.

Solution : test if the key is null
```
try
{
if (assemblyFullName.Substring(idx + 15, 4) == "null")
return false;

string publicKeyToken = assemblyFullName.Substring(idx + 15, 16);
return systemAssemblyPublicKeyTokens.Any(p => p.Equals(publicKeyToken, StringComparison.OrdinalIgnoreCase));
}
catch (ArgumentOutOfRangeException)
{
return false;
}
```

With this modification, the first call take 0.8s.
↧

Commented Issue: Slow first call to a service [94]

August 20, 2016, 5:11 am
$
0
0
The first call to a ria service is slow if they are many assemblies without PublicKeyToken (5s on my project).

The problem is the try/catch in OpenRiaServices.DomainServices.TypeUtility.IsSystemAssembly.

Solution : test if the key is null
```
try
{
if (assemblyFullName.Substring(idx + 15, 4) == "null")
return false;

string publicKeyToken = assemblyFullName.Substring(idx + 15, 16);
return systemAssemblyPublicKeyTokens.Any(p => p.Equals(publicKeyToken, StringComparison.OrdinalIgnoreCase));
}
catch (ArgumentOutOfRangeException)
{
return false;
}
```

With this modification, the first call take 0.8s.
Comments: Fixed in changeset 7813ae24073cb929252943d43af1fbe4c2a3bf57
↧

Released: 4.5.0 (Aug 20, 2016)

August 20, 2016, 5:13 am
$
0
0

4.5.0

The goal of the release is to add improved cross platform support.

This is the first release with stable WPF support as well as (at least partioal) core support to many other platforms such as windows apps (and probably xamarin apps). For an example with both Silverlight, WPF and Windows 8 app see https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient

RC1: (2016-08-20)

  • Fix #94 Slow first call to a service
    • Improved startup (and codegen) performance
  • Fix #92 EntityCollection load is very slow for large number of entities
  • Improved nuget behaviour for other targets than silverlight and desktop .net
  • Updated portable library to have the same implementation as non portable builds
  • Added netstandard 1.3 build (experimental) see https://docs.microsoft.com/sv-se/dotnet/articles/standard/library for netstandard information
  • AssemblyVersion updated to 4.0.0.0 for silverlight and portable build
    • Silverlight support automat assembly redirection to higher versions so manual redirection should not be required for any target platform

Beta3: (2016-04-17)

  • Fix #90 FormsAuthentication on Desktop Platforms
    • Desktop client now support Cookies by default (which means Forms authentication just works)
    • Can be controlled via WebDomainClientFactory.CookieContainer
  • WebDomainClientFactory can now be overridden (bug in beta2)
  • Enforce build ordering so we don't get error saying web project did not build which is one of the errors issue #73Code generation fail for WPF if xaml references local types
    • You will se a new project reference "OpenRiaServices Server Project Link" in projects with the code genereation enabled.
  • Automatically generate WebContext for .exe projects
  • Use msbuild property OpenRiaGenerateApplicationContext to control webcontext generation instead of just using SilverlightApplication variable
  • Fix #91 Difference in validation behaviour between Silverlight and .net
    • Desktop version now uses same validation logic as Silverlight build
  • ApplicationServices classes are moved to the Client assembly
    • This means that portable libraries and windows apps can now access them and have AuthenticationServices generated
  • All project now compiles
  • Appveyour compatibility - all projects now builds successfully on ci.appveyor.com


Beta2: (2016-02-16)

Beta1: (2016-02-07)

DomainClientFactory

The communication layer on the client can now be easily switched, for an example implementation se https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient

PR: https://openriaservices.codeplex.com/SourceControl/network/forks/danneesset/openriaservices/contribution/8505

What:
  • Introduces a new extension point for controlling what kind of DomainClient gets created and how.
  • Allow Desktop and Portable clients to specify a "Base uri" so that the default constructor generated by the code gen can work outside silverlight.

This should hopefully remove the last strong dependency from the "core" Client on the current WCF based Client.Web assembly so that it becomes possible to add new service communication
protocols in the future.

Why?
  • Make the core assembly independent of how we communicate with the Server.
  • Allow new communication protocols in the future such as talking to the DomainController odata service, (soap/json endpoints) etc as well as for providing a portable alternative for the current Client.Web assembly for talking with normal DomainServices.

How to use it:
  • Most user don't do anything at all, it will setup a DomainClientFactory automatically
  • For "advanced" scenarios the user can set DomainClient.DomainServiceFactory to a WebDomainClientFactory instance.

Ex: One can add the following code att application startup (ex: App ctor) before WebContext or any other DomainContext get created

```
DomainContext.DomainClientFactory = new WebDomainClientFactory()
{
ServerBaseUri = new Uri("http://localhost:51359/ClientBin/", UriKind.Absolute),
};
```

For another example with both Silverlight, WPF and Windows 8 app see https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient (WIn8 upp is not updater to beta1)
↧
↧

Updated Release: 4.5.0 (Aug 20, 2016)

August 20, 2016, 5:13 am
$
0
0

4.5.0

The goal of the release is to add improved cross platform support.

This is the first release with stable WPF support as well as (at least partioal) core support to many other platforms such as windows apps (and probably xamarin apps). For an example with both Silverlight, WPF and Windows 8 app see https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient

RC1: (2016-08-20)

  • Fix #94 Slow first call to a service
    • Improved startup (and codegen) performance
  • Fix #92 EntityCollection load is very slow for large number of entities
  • Improved nuget behaviour for other targets than silverlight and desktop .net
  • Updated portable library to have the same implementation as non portable builds
  • Added netstandard 1.3 build (experimental) see https://docs.microsoft.com/sv-se/dotnet/articles/standard/library for netstandard information
  • AssemblyVersion updated to 4.0.0.0 for silverlight and portable build
    • Silverlight support automat assembly redirection to higher versions so manual redirection should not be required for any target platform

Beta3: (2016-04-17)

  • Fix #90 FormsAuthentication on Desktop Platforms
    • Desktop client now support Cookies by default (which means Forms authentication just works)
    • Can be controlled via WebDomainClientFactory.CookieContainer
  • WebDomainClientFactory can now be overridden (bug in beta2)
  • Enforce build ordering so we don't get error saying web project did not build which is one of the errors issue #73 Code generation fail for WPF if xaml references local types
    • You will se a new project reference "OpenRiaServices Server Project Link" in projects with the code genereation enabled.
  • Automatically generate WebContext for .exe projects
  • Use msbuild property OpenRiaGenerateApplicationContext to control webcontext generation instead of just using SilverlightApplication variable
  • Fix #91 Difference in validation behaviour between Silverlight and .net
    • Desktop version now uses same validation logic as Silverlight build
  • ApplicationServices classes are moved to the Client assembly
    • This means that portable libraries and windows apps can now access them and have AuthenticationServices generated
  • All project now compiles
  • Appveyour compatibility - all projects now builds successfully on ci.appveyor.com


Beta2: (2016-02-16)

Beta1: (2016-02-07)

DomainClientFactory

The communication layer on the client can now be easily switched, for an example implementation se https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient

PR: https://openriaservices.codeplex.com/SourceControl/network/forks/danneesset/openriaservices/contribution/8505

What:
  • Introduces a new extension point for controlling what kind of DomainClient gets created and how.
  • Allow Desktop and Portable clients to specify a "Base uri" so that the default constructor generated by the code gen can work outside silverlight.

This should hopefully remove the last strong dependency from the "core" Client on the current WCF based Client.Web assembly so that it becomes possible to add new service communication
protocols in the future.

Why?
  • Make the core assembly independent of how we communicate with the Server.
  • Allow new communication protocols in the future such as talking to the DomainController odata service, (soap/json endpoints) etc as well as for providing a portable alternative for the current Client.Web assembly for talking with normal DomainServices.

How to use it:
  • Most user don't do anything at all, it will setup a DomainClientFactory automatically
  • For "advanced" scenarios the user can set DomainClient.DomainServiceFactory to a WebDomainClientFactory instance.

Ex: One can add the following code att application startup (ex: App ctor) before WebContext or any other DomainContext get created

```
DomainContext.DomainClientFactory = new WebDomainClientFactory()
{
ServerBaseUri = new Uri("http://localhost:51359/ClientBin/", UriKind.Absolute),
};
```

For another example with both Silverlight, WPF and Windows 8 app see https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient (WIn8 upp is not updater to beta1)
↧

Updated Wiki: Documentation

August 20, 2016, 5:14 am
↧

Updated Wiki: Documentation

August 20, 2016, 7:45 am
↧
Search

Updated Wiki: Porting From WCF RIA Services

August 20, 2016, 7:49 am
$
0
0

Important: The content of this page is a straight copy from http://www.openriaservices.net/blog/post/The-Open-RIA-Services-Blog/1017/Porting-from-WCF-RIA-Services-to-Open-RIA-Services/ it might be slightly out of date but should probably work.

  1. Remove all WCF RIA Services NuGet packages and DLLs. Look for DLLs with the System.ServiceModel.DomainServices and Microsoft.ServiceModel.DomainServices namespaces.
  2. Install the OpenRiaServices.Server package for all project that previously referenced System.ServiceModel.DomainServices.Server
  3. If you are using Entity Framework 6, install the OpenRiaServics.EntityFramework package.
  4. If you are using Entity Framework 4 (ObjectContext), install the OpenRiaServices.EntityFramework.EF4 package.
  5. If you are using Entity Framework 5 , you will need to upgrade to 6.
  6. Install the OpenRiaServices.Silverlight package in the Silverlight projects that previously had the System.ServiceModel.DomainServices.Client DLL.
  7. The OpenRiaServices.Silverlight package includes the OpenRiaServices.Silverlight.Core, OpenRiaServices.Silverlight.CodeGen, and OpenRiaServices.ViewModel packages in one install.
  8. Unload the Silverlight project and edit the project file.
    1. Find the LinkedServerProject tag inside the project file. Rename the tag to LinkedOpenRiaServerProject and then reload the project. Repeat for any other projects that are RIA Linked.
    2. If you are using the RiaClientUseFullTypesNames in the project file, rename it to OpenRiaClientUsefullTypesNames.
  9. Find all references to the System.ServiceModel.DomainServices namespace in your solution and replace them with OpenRiaServices.DomainServices.
  10. If you are using the DomainDataSource, then remove the System.Windows.Controls.DomainServices dll and install the OpenRiaServices.Silverlight.DomainDataSource package. The namespace changes match the dll changes.




↧
↧

Source code checked in, #585f253b710a01e7dc63c5fa1832ea1d1144f922

August 20, 2016, 8:03 am
↧

Source code checked in, #c244bbd2c51ac573ee2604b5b4d68bf563f9b8c0

August 20, 2016, 8:52 am
$
0
0
Fix issues detected by coverity * Possible NRE in WebDomainClient * Add explicit check in SubmitOperation for unsuported scenario * Possible NRE in QueryDeserializer * Remove dead code in DomainServiceVirtualPathProvider
↧

Closed Feature: EntityCollection load is very slow for large number of entities [92]

August 21, 2016, 3:20 am
$
0
0
For very large collections of dependent entities (> 10000) there is required significant time to access EntityCollection for the first time. The problem is most probably caused by multiple invocations of Contains method on List<T> Entities property in EntityCollection class.

The sample execution time for 32011 dependent entities is: 5907ms.

The solution for the problem might be to introduce additional HashSet which is synchronised with Entities and execute Contains method on it instead of List<T>.Contains.
Comments: PR merged and part of 4.5.0-rc1 release
↧

Edited Feature: EntityCollection load is very slow for large number of entities [92]

August 21, 2016, 3:20 am
$
0
0
For very large collections of dependent entities (> 10000) there is required significant time to access EntityCollection for the first time. The problem is most probably caused by multiple invocations of Contains method on List<T> Entities property in EntityCollection class.

The sample execution time for 32011 dependent entities is: 5907ms.

The solution for the problem might be to introduce additional HashSet which is synchronised with Entities and execute Contains method on it instead of List<T>.Contains.
↧
↧

Closed Task: Add NET45 dlls for all desktop libraries [71]

August 21, 2016, 3:21 am
$
0
0
We have .NET 4.0 and 4.5 libraries only for Entity Framework. This is causing code generation problems when the target is built against .NET 4.5.
↧

Edited Task: Add NET45 dlls for all desktop libraries [71]

August 21, 2016, 3:21 am
$
0
0
We have .NET 4.0 and 4.5 libraries only for Entity Framework. This is causing code generation problems when the target is built against .NET 4.5.
↧
Search

Closed Issue: Slow first call to a service [94]

August 21, 2016, 3:22 am
$
0
0
The first call to a ria service is slow if they are many assemblies without PublicKeyToken (5s on my project).

The problem is the try/catch in OpenRiaServices.DomainServices.TypeUtility.IsSystemAssembly.

Solution : test if the key is null
```
try
{
if (assemblyFullName.Substring(idx + 15, 4) == "null")
return false;

string publicKeyToken = assemblyFullName.Substring(idx + 15, 16);
return systemAssemblyPublicKeyTokens.Any(p => p.Equals(publicKeyToken, StringComparison.OrdinalIgnoreCase));
}
catch (ArgumentOutOfRangeException)
{
return false;
}
```

With this modification, the first call take 0.8s.
Comments: Part of 4.5.0-rc1 release
↧

Edited Issue: Slow first call to a service [94]

August 21, 2016, 3:22 am
$
0
0
The first call to a ria service is slow if they are many assemblies without PublicKeyToken (5s on my project).

The problem is the try/catch in OpenRiaServices.DomainServices.TypeUtility.IsSystemAssembly.

Solution : test if the key is null
```
try
{
if (assemblyFullName.Substring(idx + 15, 4) == "null")
return false;

string publicKeyToken = assemblyFullName.Substring(idx + 15, 16);
return systemAssemblyPublicKeyTokens.Any(p => p.Equals(publicKeyToken, StringComparison.OrdinalIgnoreCase));
}
catch (ArgumentOutOfRangeException)
{
return false;
}
```

With this modification, the first call take 0.8s.
↧
↧

Created Issue: [Required] incorrectly added to database generated properties [96]

August 29, 2016, 1:10 pm
$
0
0
When using EntityFramework and fluent configuration (or a code generation strategy without [DatabaseGenerated] attributes Ria Services will incorrectly infer that databasegenerated properties such as rowversion fields of type byte [] are required which can result in these entities not being able to be saved.

The issue has ben solved for properties with the [DatabaseGeneratedAttribute] in changeset 644c19da but the fix only worked for properties where the attribute was applied directly to the property and not for classes where it was specified in edmx or using code first fluent Api.


This should make old workarounds such as https://social.msdn.microsoft.com/Forums/en-US/9de7a69a-6dbf-4c06-aa68-62f34227dd8d/remove-required-attribute-on-entity-exposed-by-wcf-ria-service?forum=silverlightwcf obsolete.


↧

Source code checked in, #a9a8520bd98e847614aa5913dee573851744ae14

August 29, 2016, 1:12 pm
$
0
0
Don't generate RequiredAttribute for database generated values Fix #96 Models with database generated properties without [DatabaseGeneratedAttribute], such as when using fluent configuration, would cause an RequiresAttribute to be incorrectly inferred.
↧

Edited Issue: [Required] incorrectly added to database generated properties [96]

August 29, 2016, 1:23 pm
$
0
0
When using EntityFramework and fluent configuration (or a code generation strategy without [DatabaseGenerated] attributes Ria Services will incorrectly infer that databasegenerated properties such as rowversion fields of type byte [] are required which can result in these entities not being able to be saved.

The issue has ben solved for properties with the [DatabaseGeneratedAttribute] in changeset 644c19da but the fix only worked for properties where the attribute was applied directly to the property and not for classes where it was specified in edmx or using code first fluent Api.


This should make old workarounds such as https://social.msdn.microsoft.com/Forums/en-US/9de7a69a-6dbf-4c06-aa68-62f34227dd8d/remove-required-attribute-on-entity-exposed-by-wcf-ria-service?forum=silverlightwcf obsolete.


↧
Viewing all 124 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>