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
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.
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.
Any progress on this feature? What makes you thinking that the AppDomain is recycling? Because static variables seems to stay alive.
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
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
Please login first to submit.