WCF services really not in the right place (and other issues)

[dodexahedron]

The code for all the WCF services lives in one of the DLLs (SEModAPIExtensions), rather than in SEServerExtender, itself, which is a very odd pattern. It also makes it a lot more difficult to integrate it with anything else that may want to talk to SESE, since all the configuration is hard-coded in that DLL.

I propose a pretty massive change to how the WCF services are set up. Since this is still "alpha," and I highly doubt anything has been built against them that isn't already in this project, breaking changes would be more than acceptable. I started the initial phase that would make this possible in a commit I made to my fork, by separating the WCF service contracts out to their own files, so the service implementations can be extracted to where it makes sense to implement them.

Here's how the WCF services should be set up, to make this actually extensible and, most importantly, easy to code for in the future:

• Move WCF server-side implementation to SEServerExtender. The client doesn't need an implementation of the server, but that's exactly what this does.
• Move all service configuration to app.config, so that users may configure it as they see fit (allowing connections from other machines being the first major obvious advantage, here).
• Manually implement the client-side proxy classes in any application that uses them, in this project. This will make SEServerGUI significantly smaller, as the service proxy classes generated by Visual Studio are...bad.
• By default, the WCF services should be set up as net.tcp services, since who the heck is going to be manually writing a SOAP client for this? With manual configuration available, they'll be able to expose SOAP endpoints if they really want to, but the net.tcp endpoints will come with a significant performance bonus.

Those are the key points, really. It will be necessary to hold on to static references to the server object, in SESE, so that the service can access it whenever it pleases. The self-referencing "Instance" member is an odd and error-prone way to do this. It should be application-scoped, since it's an application-relevant object. We'll also need to be careful about how that object is treated across appdomain boundaries, for purposes of plugins. Perhaps plugins should be loaded into their own appdomains and all access to the core be done via exposed WCF service methods. That'd help keep the barrier to entry to write a plugin low as well as provide pretty effective isolation between plugins and SESE itself. Plus, it opens up the interesting prospect of having multiple servers handling individual functions, if necessary, for large worlds with many players and processing-intensive plugins, with no extra development cost for SESE at all.

If this thing is going to continue to be a real mod platform and not just a host for the small handful of plugins that are part of the project, it NEEDS to be easier to develop against.

I'm using my fork as a branch to begin some of this work. If you like the idea, then we can merge it upstream to this fork and work in a real branch so it isn't so fragmented. In other words, I'm more than willing to contribute my time to this project, to do the things I said above and whatever else may come along.

[dodexahedron]

I will post smaller issues for a couple of these items.

[Tyrsis]

I posted in another post about WCF you made, but I will repeat it here. Everything you've laid out makes sense, but I do not have time to implement it. The WCF stuff was all left over from when chessmaster implemented a WCF solution. He tended to do things fast, but then kind of left them, as his schedule was also hard to work around in terms of getting things done.

The scope of what I work on in real life does not include WCF, so my familiarity with it isn't very high.

Here is the thing at the end of the day. Two other people have done what I would call "bite off more than they could chew" when it comes to this project. One person who was helping me for a short period of time said, "fuck it" and decided to try to make a completely separate extender. They have since completely disappeared. Another person who wanted to help ended up being drowned in the fact that it was just out of their depth due to obfuscation and size of the project.

All that being said, if you'd like to take over the WCF (and completely change it (yes please!)) then go for it, I will completely support that, and it would help immensely, as I don't think I will ever really get a chance to actually sit down with it. Realistically extender is mostly maintained right now for me to maintain the plugins for it.

[dodexahedron]

Yep, that's exactly what I'm offering. I don't expect other people to pick up the slack of large-ish scoped features I suggest.

And if you're saying you support ditching the existing WCF implementation in its entirety, that'll actually make my life a LOT easier, since there are far easier ways of doing WCF than the way it was originally done in this project.

At the risk of getting a little off-topic, what's your view on supporting/using .net 4.5? There are some very real improvements (not the least of which are performance-related) that I'd love to be able to take advantage of. I'd greatly appreciate being able to use the async pattern in all this, especially with the WCF methods.

[Tyrsis]

Yes, you can ditch it completely. It doesn't work at all, and I can't maintain or even compile it properly. (Well I can compile it, but the second I regenerate the Service References, it basically generates 36000 lines of garbage proxies (which it doesn't even need) and basically bombs VS for me, or just flat out errors.). Like you said above, this probably requires manual proxying of objects, the problem is there's a lot of damn objects to proxy.

As far as 4.5. The issue is that the game is 4.0. I tried compiling in 4.5, and then it causes a host of other issues (it crashes for people on startup, but only a select people, I believe it's a .NET incompatibility, but it became a nightmare trying to figure out what was causing it as I didn't have 2012 available to me which I believe was the issue (maybe?)).

If you can get 4.5 to work without it crashing everyone using windows server 2012 (I believe that was the host OS that was causing issue), then I'd say it would be fine. I have nothing against it except that I just couldn't get it to work with everyone's setup.

Anyway, I added you on steam, and we can discuss it more if you're willing to take it on. Please note that realistically no one except myself writes plugins for extender, which is slightly a shame, as it gives far more power than modapi does at least in a dedicated server environment.

[dodexahedron]

Visual studio 2013 is free now, so you can certainly use that, even for 4.0, if you like.

I'll give 4.5 a shot, but I won't force it if it gives too much trouble.

[Vl4dim1r]

We are actually the ones that found out the issue with compiling with .net 4.5 and the result not running on Windows Server 2008. We have good reasons for having to run winserv08, and it isn't as simple as "just upgrade to a newer OS". I just remembered this issue because we are having trouble getting a new version of our community plugin to load. It works fine on a windows 8 based server, but not on a windows server 2008 based server.

On the other hand, we did just finally get our winser08 install legal, so we can actually run updates now. I saw some pending updates for .net 4.5 fixes, so maybe its just the case of an un-updated OS. I will confirm as soon as we are done updating. - UPDATE: This didn't help at all.

Another update: Scratch all that. I decided to try another winserv12 install, and managed to make it work this time. As far as I am aware, we were the only ones to report any issues with winserv08 and .net 4.5, so, if no one else objects, by all means switch to 4.5, barring further issue.