OWIN self-hosted application in single binary

[itg-assistant]

Martin Häusle asked 2017-09-07 10:36:17 UTC

Hello

We really like the idea of using self-hosted Wisej applications using OWIN. But there is one feature we are missing. It would be great if we could run the application without any other files like web.config, Default.html or Default.json. Just a single binary like “Wisej.Application.IE” using ILMerge.

I know that using OWIN there is no need for web.config any more. Also Default.html can be served by changing the FileServer’FileSystem from PhyiscalFileSystem to EmbeddedResourceFileSystem.

The only thing we are struggling is the Default.json. Is it possible to load this config from an embedded resource or provide the config otherwise?

best regards

Bernhard

[itg-assistant]

Frank (ITG) answered 2017-09-07 13:25:45 UTC

Hi Bernhard,

thanks for your question.

While we can bypass default.json it won´t really help.

OWIN is just an interface specification implemented by Katana (Microsoft´s web server implementing OWIN).
We use Katana/OWIN and added 2 of our OWIN middleware: Wisej and ASP.NET.

The ASP.NET middleware instantiates the System.Web host which runs in a separate AppDomain and can only load assemblies from the /bin subdirectory.
Wisej needs the System.Web subsystem to process requests/responses/websocket etc.

Plus our implementation also supports all ASP.NET code, controls, pages, webforms, handlers etc.
There is obviously no other implementation that does it currently.

Coming back to your question:
One way to pack it all in one EXE would be to use an app virtualization packager, but it may not work with the System.Web application host
and real .NET packagers are hard to find. Xenocode was one but it does not seem to exist anymore.

Hope that helps .

Best regards
Frank

[itg-assistant]

Martin Häusle answered 2017-09-18 14:45:45 UTC

Thank you for your answer.

The problem you described with the AppDomain is not a problem since it’s a single dll anyway and gets injected by your WisejHost. And I still don’t see a reason why it should not work.

But despite your answer I was still trying to continue. And I have the feeling that there is some progress. I think I’m able to start initializing a WiseJ application. But it stuck on initializing. If I check the requests it seems quite promising.

http://localhost:9000/wisej.wx

http://localhost:9000/resource.wx/init?_sc=1505743791040

http://localhost:9000/app.wx?_sc=1505743791411

http://localhost:9000/resource.wx/init?_sc=1505743791812

http://localhost:9000/app.wx?_sc=1505743792150

http://localhost:9000/resource.wx/init?_sc=1505743792646

http://localhost:9000/app.wx?_sc=1505743793061

http://localhost:9000/resource.wx/init?_sc=1505743793601

…

But as you can see the application restarts with init after the app.wx call. Do you have any idea about that behavior?

I attached my demo project and a screenshot with the partly initialized application.

I modified the WisejHost.cs and added the method CurrentDomain_AssemblyResolve to bypass the required Wisej.Web.dll because it is merged anyway. The WisejHost also uses the EmbeddedResourceFileSystem to serve the default.html.

I merge the assemblies with merge.bat

It would be very nice if this would we possible.

best regards

Bernhard

[itg-assistant]

Luca answered 2017-09-20 15:49:39 UTC

Looks like it may work, I don’t know what’s causing the refresh. I’m afraid it’s System.Web detecting something that causes a reload of the AppDomain. I’ll keep you posted with my tests.

[itg-assistant]

Martin Häusle answered 2017-10-02 12:08:19 UTC

Any progress on this feature?
What makes you thinking that the AppDomain is recycling? Because static variables seems to stay alive.

[itg-assistant]

Martin Häusle answered 2017-10-09 12:17:38 UTC

Any progress on this feature? What makes you thinking that the AppDomain is recycling? Because static variables seems to stay alive.

[itg-assistant]

Luca answered 2017-10-09 20:21:35 UTC

The problem was not the recycling. It was that ILMerge removes the assembly attributes when merging so it removed the WisejResources from Wisej.Web.dll. The [attribute:WisejResources] that you added to ServiceWebServerWiseJDemo.UI.AssemblyInfo.cs didn't have the exclusions, which causes Wisej to merge qx.js and qx.min.js and others all into wisej.js.

Basically the loader.js was loaded 3 times causing the browser to keep loading.

I changed the attribute to [assembly: WisejResources(ExcludeList: "qx.js, qx.min.js. Wisej-Loader.js")] and it works.

I also added some code to extract Default.js at startup. You only need 1 file now, the json is extracted at startup. At the moment there is no way to change that - you'd have to use some convoluted reflection code. I can see if we can add a public constructor taking a json string.

[itg-assistant]

Martin Häusle answered 2017-10-10 11:56:37 UTC

Thank you very much for figuring this out. This helps us a lot.

Extracting the default.json is not possible because we don’t allow the Windows service to write to its directory. With a little reflection magic we are able to fill the configuration cache.

Our idea for the Configuration would be some kind of factory like the VWG “IFormFactory” but for configurations. Maybe define the type in appSettings. (not a usecase for us at the moment but I have some ideas about that)

Thank you for helping us with this.

[itg-assistant]

Luca answered 2017-10-10 17:02:58 UTC

I sent you a dev build along with an updated ServiceWebServerWisejDemo. It uses a global event Configuration.LoadConfiguration similar to the Assembly.ResolveAssembly that lets you load a configuration instance from a simple json.

[itg-assistant]

Bernhard Lang answered 2017-10-11 11:52:07 UTC

Can you please send it to my address. I was posting as our purchasing clerks account and according to him he didn’t received the build.