Hi Jacek!

I have added a section on instance-based remoting to the update docs.

Also, a new WebSharper build (version with the cookie handling fix is available on daily builds feed: http://daily.websharper.com/nuget Can you check if this resolves your problem with the incorrect cookie header? Thanks!

By on 1/10/2019 10:32 AM ()

Yes, it helped.

Thanks a lot, Jacek

By on 1/11/2019 1:47 PM ()

Hi, thanks for verifying! We have released it to nuget.org. https://github.com/dotnet-websharper/core/releases/tag/

By on 1/15/2019 4:12 AM ()

Hi Jacek, looks like three of the four issues are being looked at, can you please file the localization issue as a separate GitHub ticket, giving some extra details? Thanks.

By on 1/10/2019 12:36 AM ()

Can you describe what your 3.x setup looked like with respect to the HTML templates in libraries? Do you mean that you marked those as embedded resources and they fail to unpack now? Or do you mean that the build doesn't copy them anymore?

By on 1/9/2019 4:21 AM ()

In 3.6 it was simple file with no action:

<None Include="Main.html" />

and no build event copying this file was defined. Right now, WebSharper expects it to be in main project folder.

By on 1/9/2019 2:14 PM ()

These files have to be coupled with the library to ensure that they are available where they are consumed. How else it worked before, I am not sure. Loic, any idea?

By on 1/10/2019 12:33 AM ()

The old style template compiles directly into a tree of calls to element functions, so it didn't need the file at runtime.

That being said, we can still keep the file content from compilation, and either use it in ServerLoad.Once mode when the file is absent or add a ServerLoad mode that uses it and doesn't look for files at runtime. I think the latter would be better.

By on 1/10/2019 8:34 AM ()


You can find the documentation on upgrading from 3.x to 4.x and the breaking changes here: WS4UpdateGuide. There has been some breaking changes since 4.0 too, but nothing I remember that would tie in with these problems, but you can find them in the GitHub release notes. The biggest one is that WebSharper.UI is the preferred and supported UI library, although there are still 4.5-compatible packages names WebSharper.UI.Next (name has been simplified to WebSharper.UI with 4.1) and WebSharper.Html for easier upgrading but those have been not updated with newer features and fixes since a while.

Of your issues, the AddHandler one may be caused by the interface semantics change if you are using an interface for remoting: now interfaces can be used as JavaScript mixins, translated names of implementation methods are enforced to be the same as defined in the interface type. This makes them not well suited to be used with AddHandler, which now only works with class types (it can be an abstract class without implementation, so still can be defined in a shared project between client/server while keeping the two main projects separate).

On the other points, can you share some code, snippets or minimal sample project to reproduce? Thanks!

Regards, András Jankó

By on 1/8/2019 4:06 PM ()

As far as the cookie example is concerned, the following exception occurs:

[Exception: Cookie header syntax invalid]
   WebSharper.Sitelets.WebUtils.get_Cookies$cont@107(NameValueCollection d, FSharpOption`1 matchValue, Unit unitVar) +457
   WebSharper.Sitelets.AspNetRequest.get_Cookies() +92
   WebSharper.Sitelets.respond@146.Invoke(Response response) +197
   Microsoft.FSharp.Control.args@823-1.Invoke(a a) +63
   Microsoft.FSharp.Control.AsyncIAsyncResult`1.GetResult() +356
   Microsoft.FSharp.Control.AsBeginEndHelpers.endAction(IAsyncResult iar) +64
   <StartupCode$FSharp-Core>.AsBeginEnd@1995.Invoke(IAsyncResult iar) +40
   WebSharper.Sitelets.HttpHandler.System-Web-IHttpAsyncHandler-EndProcessRequest(IAsyncResult result) +13
   System.Web.CallHandlerExecutionStep.InvokeEndHandler(IAsyncResult ar) +152
   System.Web.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult ar) +125

Such cookies did not caused this in WebSharper 3.6.

I guess, that the problem is the Uncategorised_Warning_Cookie token, that has no value assigned - it's not HTTP-compliant.

By on 1/9/2019 2:50 PM ()

Thanks, the stack trace helps. Indeed, this seems like a bug introduced when adding support for ASP.NET Core by making WebSharper's Http.Request type not depend on any ASP.NET 4.x types and cookie parsing was rewritten by hand. Created ticket: https://github.com/dotnet-websharper/core/issues/1039 A fix will be released soon.

By on 1/9/2019 4:18 PM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper