Solved Craftbukkit development via Visual Studio 2012.

Heya's.

I've spent a few hours on this but I finally got Craftbukkit working inside Visual Studio 2012 via .NET <-> Java bridge. In that i've come up with a hook that enables .NET developers to write plugins for servers that run Craftbukkit via IKVM.

The idea is you basically take the current bukkit server (As-is) and spin it up via iKVM. Then you import the DLL/EXE created via IKVM into your VisualStudio project. Now given Craftbukkit specifically looks for .JAR files you can do one of two things. The first being write your code, then convert your .dll to a .jar (works, but slow in development time given you will want to debug etc).

The second option (which for me works) is that there is a master manifest manager, whereby you basically tell it where your plugin.yml files are located but instead of loading in external dll's (which I may still add later) it basically will parse that file and inject the class instantition via JavaClassLoader (using .NET reflection I was able to trick the normal routines into using the as-is in memory instances vs loading the .jar files via inputstreams).

Is this something folks would be interested in and testing?



I've managed to also load in both Java and .NET plugins together...plus console has colors! ... and its using 64bit .NET which should allow for more memory (downside is its 100% windows only of course - but am thinking about Mono now..)

 

Looks cool, but I don't really get the point of it? My console has color anyways for some reason ._.

I like the more memory thing, but what exactly is it? A custom CB?

 

It's still Craftbukkit as-is, in that it pulls from the same source repository as everyone else does via their normal .jars.

eg; my home TeamFoundation Server (Microsofts ver of source code mgmt) pulls down a nightly build of craftbukkit snapshot. It then runs IKVM on the said jar (IKMC craftbukkit.jar) which then generates proxy versions of the jar in .dll format. It then takes that DLL and compiles it in with my plugin connector wrappers. Which then enables you to not only write your plugins inside Visual Studio + .NET but at the same time you'll always have parity with the current release.

Like I said, the downsides are:

• Windows Only (Mono may solve some x-plat issues here later).
• No Hotswapping (When you debug you have to stop / start server each time - do miss that in java!)
• Plugin Priorities are a bit off. Its more of a bug but right now I'm having some minor issues with handling the plugin Queue (ie who has right of way to load first as of right now .jar plugins always trump .win plugins)

Upside:

• LINQ to SQL / Entities access via plugins!
• Azure/Amazon Access via plugin(s) using .NET existing wrappers.
• Visual Studio access (for all those .NET boffins - I worked at Microsoft so i'm always a fanboi for that tool).
• Easier access to Windows SDK's ... I've made a quick plugin that has a live tile for windows8 which alerts me when my name is called via the server (toast pulls up etc). This can then go deeper as you can then integrate WPF/Silverlight with your plugins

 

It is interesting, and i'm a c# developer myself, and of course, know that visual studio is far superior to any other IDE out there. It is amayzing and then some, and I do miss it at times. Having said that, most servers run on linux simply because a GUI OS is expensive where server performance is critical. Java and c# are like brother and sister anyway, its not really that hard to go from one to the other. I think its a very interesting idea though.

 

Agreed on all points. I find Java easy to work with but I also find it lacks certain features that I miss in .NET that and I'd like to also do more with a craftbukkit server around external API's / web. Given that IKVM is a Mono/.NET implementation of JVM it seems to also have more capacity for better performance than Java so that was an interesting profile to run. I've also found the whole plugin development a lot faster now as a result but that I suspect is more to do with being a .NET guy than Java these days (that and I used to be the Product Manager for .NET so i'm always going to be a little more comfortable with .NET than Java).

I'll release the source for this once I tidy it up but overall I've made it so that Java mod makers and .NET makers can still work along side one another with the only dependency between the two is that they have to run this on a Windows box instead of a *NIX (which yes has its ups/downs).

eg: I wrote a custom plugin that uses Vault/IConomy (jars) (ie didn't decompile them or anything just used them as-is).

I'm also thinking of a client-side version of this that uses a wrapper / injection routine that enables developers to create mods that work with servers in a more efficient manner.. in that using generic packets between client/server one doesn't have to rely on marrying up the block/item references directly..as it can be one that auto-generates an id for custom additions to the game and the UI then automatically associates the animations/textures with this.

But then this would rule out Mac/Android versions of the game (well kind of ...assuming one takes on mono dependency issues)

 

Can you explain how you did this?
Well, I downloaded IKVM and I have my .exe version of Spigot (bukkit).
From there, I am not 100% sure what to do; I added the exe as reference in VS2013, is that right?