What does this mean? (Visual Studio C# 2010)

[FiresThatBurn]

http://gyazo.com/87ae0d828f00f74cd52f7e577218a8a2

Can someone explain what happened? I am using a class library with the files referenced and everything. This appears when I try to debug.

Edited June 22, 2014 by Some_Random_Guy
IMG wont work with gyazo :P

[Greys]

what's a gyazo

[DMagic]

You don't need to bump a post that's still at the top of the list...

In my experience debugging doesn't work on VS. Using a setup that works on Monodevelop doesn't work on VS and gives me an error similar to the one you're seeing. It's not exactly the same message though, and I've never really tried to get it working, so I have no advice other than to try something similar on Monodevelop.

[tobyb121]

This error is when you are trying to debug a class library project. A class library is a dll file which includes classes that can be used by another program. For example when you reference UnityEngine.dll in your KSP add-on I allows you to access lots of the unity classes like Vector3 and GameObject. A dll has no entry point, meaning the code doesn't create a program, it is just available to be used by one. In order to test your dll you need to build it (under Build>Build Solution) find the output dll (under Project Directory/bin/Debug) and copy this into your KSP directory for your mod, then run KSP. You can use batch files to do all of this and change your project settings in VS to run the batch file when you press the debug button.

[Echo 8 ÉRÀ]

This error is when you are trying to debug a class library project. A class library is a dll file which includes classes that can be used by another program. For example when you reference UnityEngine.dll in your KSP add-on I allows you to access lots of the unity classes like Vector3 and GameObject. A dll has no entry point, meaning the code doesn't create a program, it is just available to be used by one. In order to test your dll you need to build it (under Build>Build Solution) find the output dll (under Project Directory/bin/Debug) and copy this into your KSP directory for your mod, then run KSP. You can use batch files to do all of this and change your project settings in VS to run the batch file when you press the debug button.

Or you could just use MSBuild Tasks and accomplish the same thing without the hassle of dealing with batch files:

Edited June 22, 2014 by Echo 8 ÉRÀ
Added link since embedded videos don't seem to have a full screen option

[pizzaoverhead]

The reason you're getting the "A project with an Output Type of Class Library cannot be started directly." error is that you have Visual Studio set to try and run the plugin. Plugins can't run on their own. You can change it by right-clicking your plugin's project in the Solution Explorer window and clicking Properties. On the Debug tab, you can change the Start Action from "Start project" to "Start external program" and browse to the location of KSP.exe. Now, any time you press F5, KSP will start.

Even though it starts, your plugin is still in your project directory, not the KSP directory, so you won't see the changes you've made in-game. To fix this, you'd need to copy the DLL into the KSP directory after every build. You can do this automatically by clicking on the Build Events tab in the project's properties, and adding a Post-build event command line. This command will copy your DLL to the given plugin folder in the KSP directory every time you build. Change the path to point to your own KSP and plugin location:

xcopy /y "$(TargetPath)" "C:\Games\Kerbal Space Program\GameData\PluginName\Plugins"

$(TargetPath) is a magic Visual Studio variable that contains the full path to the plugin, including its filename. You can see what variables are available and what they mean in the Build Events tab by clicking "Edit Post-build ..." and clicking the "Macros >>" button.

Edited June 23, 2014 by pizzaoverhead

[xEvilReeperx]

I like to keep a copy of my plugin directory with the source (so any related assets can be added to source control) so my post build event looks like this:

set ksp=full_ksp_path_to_gamedata_here
robocopy "$(ProjectDir)bin\$(Configuration)" "$(ProjectDir)GameData\$(ProjectName)" $(TargetFileName)
robocopy "$(ProjectDir)GameData\$(ProjectName)" "%ksp%\$(ProjectName)" /E /xo

REM a little hack because robocopy reports code 1 on file copy success
REM build process will interpret non-zero as an error and report failed build
set rce=%errorlevel%

if %rce%==1 exit 0
if %rce%==2 GOTO ExtraFiles
if %rce%==3 GOTO ExtraFiles
if not %rce%==1 exit %rce% else exit 0

:ExtraFiles
echo WARNING: Extra files in output dir
exit 0

Then any time I work with any assets, I keep them in $(ProjectDir)GameData\$(ProjectName)\ and can edit them at will. Any changes will be moved into the KSP directory next time I rebuild. It's convenient, and I can delete any directory in my dev install as I like without worrying about accidentally losing something important