08-31-2014, 07:11 PM
Hello, and welcome to the forum.
What wrapper are you using, the Java Service Wrapper - http://sourceforge.net/projects/wrapper/ ? I don't know much about it, but I would expect that it manipulates the input stream handles somehow, which makes MCS believe that its input stream has closed, which is a signal for the server to shut down gracefully. I'd recommend using the original Microsoft tool, srvany.exe, as the wrapper; unfortunately finding a proper download is troublesome these days. Or perhaps look through the Java Service Wrapper's documentation if it says anything about the input stream, and perhaps a way to make it not close the stream.
As for running from VS, you're really close. Just open the solution in VS, get the Solution Explorer window (by default docked to the left), find the MCServer project there, right-click it and select "Set as startup project". As it is, there's no way for CMake to set the startup project while it generates the solution file, and VS defaults to the first project in the solution, which unfortunately is CMake's internal housekeeping project, so it cannot be run directly.
The next step is to set the Working directory, so that the server can find its stuff when it starts up. Right-click on the project once again, select Properties, and in the dialog, navigate to Configuration Properties -> Debugging in the tree on the left side, then change Working directory to "..\MCServer" (without the dblquotes). Note that if you switch to a different configuration (release / profile / ...), you'll need to do this again, or you can simply select All configurations in the Configuration combo at the top of the dialog before changing the value.
That's it, now you should be able to run without any problems.
I recommend one more thing - set up MS Symbol servers in order to improve the debugging accuracy. In VS, use the Tools -> Options menu, navigate the left tree to Debugging -> Symbols, make sure that Microsoft Symbol Servers is checked in the list and that the cache directory under the list is valid, select the "All modules, unless excluded" radio button and confirm the changes in the dialog. The first debugging session that you start afterwards will take quite some time to start, don't worry, it's a one-off action, VS is downloading public symbols for all the MS system DLLs that MCServer uses from MS servers, so that you get complete stack traces. It took my computer some three minutes to display the MCServer console and another three minutes for the server to start; YMMV. With the new settings, whenever you hit a breakpoint or a crash, the callstack window will have the most accurate callstack available, instead of only guessing through half the entries.
What wrapper are you using, the Java Service Wrapper - http://sourceforge.net/projects/wrapper/ ? I don't know much about it, but I would expect that it manipulates the input stream handles somehow, which makes MCS believe that its input stream has closed, which is a signal for the server to shut down gracefully. I'd recommend using the original Microsoft tool, srvany.exe, as the wrapper; unfortunately finding a proper download is troublesome these days. Or perhaps look through the Java Service Wrapper's documentation if it says anything about the input stream, and perhaps a way to make it not close the stream.
As for running from VS, you're really close. Just open the solution in VS, get the Solution Explorer window (by default docked to the left), find the MCServer project there, right-click it and select "Set as startup project". As it is, there's no way for CMake to set the startup project while it generates the solution file, and VS defaults to the first project in the solution, which unfortunately is CMake's internal housekeeping project, so it cannot be run directly.
The next step is to set the Working directory, so that the server can find its stuff when it starts up. Right-click on the project once again, select Properties, and in the dialog, navigate to Configuration Properties -> Debugging in the tree on the left side, then change Working directory to "..\MCServer" (without the dblquotes). Note that if you switch to a different configuration (release / profile / ...), you'll need to do this again, or you can simply select All configurations in the Configuration combo at the top of the dialog before changing the value.
That's it, now you should be able to run without any problems.
I recommend one more thing - set up MS Symbol servers in order to improve the debugging accuracy. In VS, use the Tools -> Options menu, navigate the left tree to Debugging -> Symbols, make sure that Microsoft Symbol Servers is checked in the list and that the cache directory under the list is valid, select the "All modules, unless excluded" radio button and confirm the changes in the dialog. The first debugging session that you start afterwards will take quite some time to start, don't worry, it's a one-off action, VS is downloading public symbols for all the MS system DLLs that MCServer uses from MS servers, so that you get complete stack traces. It took my computer some three minutes to display the MCServer console and another three minutes for the server to start; YMMV. With the new settings, whenever you hit a breakpoint or a crash, the callstack window will have the most accurate callstack available, instead of only guessing through half the entries.