MechJeb2

MechJeb2

4M Downloads

Building Mechjeb2 from source?

pantheis opened this issue ยท 22 comments

commented

Normally I'd pose this question on the forums, but... yea.

At the risk of looking like a complete noob at C# and Visual Studio (I am), could anyone give a set of step by step instructions on getting the source loaded correctly into a VS project and built?

I tried to do it myself and while VS finally reported no errors and I built a release branch mechjeb2.dll file based on the current dev branch source, copying that over the existing plugin dll resulted in mechjeb2 not showing up in-game at all. The parts were there, but they weren't loading the plugin.

Not at all sure what I'm doing wrong. I followed as much of the directions at http://wiki.kerbalspaceprogram.com/wiki/Creating_your_first_module as seemed to apply.

My ultimate goal is to get a Jenkins build system going but I want to understand C# and VS project files first. I have a decent amount of experience with Java coding and Jenkins for building those but nothing with C# and VS.

commented

Probably you are targeting version 4.5 of the .NET framework. You need to target version 3.5, which is the one Unity is compatible with. You can find the setting in your project properties in VS.

If this doesn't work, you should look in KSP_Data/output_log.txt and read through the loading messages to see where an error is being thrown.

commented

Good call on the .NET 3.5. Switched that up, but now I'm getting the following in the output_log.txt and to be honest, don't have a clue where to go with it.

MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "MuMech.Properties.Resources.resources" was correctly embedded or linked into assembly "MechJeb2" at compile time, or that all the satellite assemblies required are loadable and fully signed.

commented

Why don't you guys just include a project file? Even if we have to search/replace part of the paths to make it match where our files are, I'd think that'd be a lot easier.

commented

@pantheis: I'm not sure from that error what exactly is going wrong, but I'd make sure you have included the Properties folder and all its contents in your project.

@Tallinu: Well, I think all the developers would need to have an identical .csproj file for us to be able to include it version control. Since our disks are all set up differently we don't have identical .csproj files and we'd be constantly overwriting each others .csproj files if we included it the repository. Is there a way around this? It would be nice to be able to include a project file.

commented

Anatid, I have. In VS, I told it to import a new project from source, selected the MechJeb2 folder and let it do it's thing, confirming that the proper resources were all in place including in the subfolder.

On your comment about the .csproj file, the absolute path structure that seems to be imposed in it is one of the reasons I greatly dislike the way Visual Studio does things. I'm used to ant and java, where you can use relative paths and it's a cinch to import somebody else's project (assuming they don't hard code absolute paths).

The .csproj file is just an XML file, as far as I can tell. Even a copy of a developers functioning file pasted to pastebin for a reference would probably help me debug what's happening. I'm positive this is some project setup issue that isn't being handled correctly.

commented

@Anatid Couldn't you just make a copy of the project file in some folder of the repo, which you don't actually use as your main project file? Everyone could have that copy of it without it affecting their own working environment, and someone downloading the repo for the first time would have a working project file that they could move to the appropriate location or import in some way.

commented

OK, here's my current MechJeb2.csproj file: http://pastebin.com/KC225ww2

commented

I just realised that and bingo lots less errors I just need to knobble 9 errors like these:

/home/chris/development/MechJeb2/MechJeb2/Properties/AssemblyInfo.cs(12,12): Error CS0579: The attribute `System.Reflection.AssemblyTitleAttribute' cannot be applied multiple times (CS0579) (MechJeb2)

all 9 errors are in this file, also there doesn't seem a way in monodevelop to target net 3.5 - I'm thinking that may be an issue?

Apologies if my blundering seem a bit lame I'm new to c# ... !

commented

Found I have a duplicate AssemblyInfo.cs that monodevelop had kindly made for me!
All compiles get an AR202 component in the game but no windows?
Will let you know if I get it working I could probably host an occasional snapshot for others to download if needed?

commented

I'm in orbit thanks to MechJeb 2.0 ! - (needed to target net 3.5 as suspected)

I intend to host occasional snapshots on my website if thats OK the developer...

https://github.com/MuMech/MechJeb2/wiki/Compiling-MechJeb-2

commented

Especially with the forums down and for those of us not owning windows, a weekly compiled snapshot would be really nice, I know its not release yet but I'm sure many people would appreciate and early look at mechjeb2 if only for the autodocking! even with remaining issues from what I see on youtube its still well worth having (nice work!)
I did attempt a compile on Linux but it seem to need Unity to compile?? - not something I can find the money for just at the moment...

commented

@Tallinu: We may be able to do something like that; I'll look into it.

@chriscamacho: Happily you don't need Unity. You just need to reference a couple of .dlls that come with KSP, namely Assembly-CSharp.dll and UnityEngine.dll. On Windows these are in the KSP_Data folder; I'm not sure where they are on Linux (are they still .dll's on Linux?).

r4m0n is looking into setting up a system to automatically compile a .dll periodically from a snapshot of the dev branch so people can try the development version if they want.

commented

chriscamacho, thanks for the wiki article on compiling MechJeb 2 from source. It sounds like you originally had the same issue I had while trying to compile it under Visual Studio 2012 in Windows, where it compiled, the part shows up in the VAB but there's no functionality to it. In my case, I was getting what I stated earlier in the log. I'm glad you got yours working and I'm sure your experience will help me, soon as I get some time to work on it. :)

commented

No success here with VS 2012 too, Even with Anatid project file I still have the resource error.
But if you comment the code of CheckSkin() in GuiUtils.cs the resource are not needed anymore, so it's a workaround (It won t use Romfarer skins if you have his addons )

commented

By resource errors, are you talking about the "MissingManifestResourceException" that I listed earlier or something else? Maybe it's VS 2012 that's the issue? Also, if I can get MechJeb2 skins back even with Romfarer installed, that would absolutely be stellar.

commented

Project files can (and usually do) store relative paths to other files, so there shouldn't be any problem creating a single project file that would work for everyone.

commented

@asmi84 - that would be awesome! Do you know of any compile issues using VS 2012? I can get the Mechjeb2.dll file built with no errors from VS, but I get that "MissingManifestResourceException" listed earlier in the KSP log during loading and the MJ interface doesn't show up in-game.

commented

I'm not sure about mono develop in windows but I found it to be a lot more user friendly and less bloated than something you'd expect from ms - I'd recommend you give it a try...

while I'm not a frequent windows user as I understand it 32 and 64 bit programs are installed in different locations and likely you'd want your source in your own directory both of which are likely to break relative paths?

I can add the mono develop project file to the wiki or probably better pastebin but without looking I'd reckon it has a whole heap o absolute paths but could be a guide maybe ??

commented

I found how to make it works in VS Express 2012. Open the Project Properties and change the default NameSpace to MuMech.
It seems the namespace in Resources.Designer.cs is not used...

commented

That's odd that you had to change the default NameSpace to MuMuch, since the pastebin earlier has it listed as MechJeb2. So odd!

-edit-
Confirmed that this fixed it with VS 2012.
Assembly Name: MechJeb2
Default namespace: MuMech

commented

Can I suggest that one of you guys with visual studio add to the wiki here so that all the info required is in one place, then at least others won't have your strife!

commented

@chriscamacho - Will do, probably sometime this weekend.

I managed to get this compiling using the .csproj file posted earlier (with slight editing to correct the paths to the DLL files included with KSP that are needed) along with removing the copy part at the end. I ran into no weirdness or other issues. I haven't been able to test the resulting dll yet, but we'll see.

The problem I see with moving this into a Jenkins autobuild system is that the required DLL files from KSP aren't easily available in an automated way and there's no .csproj file included with the MechJeb2 source that gets updated as new files are added, old ones are removed or current ones are renamed. This will cause the copy I have to get out of sync potentially very quickly.

So far, I'm not seeing any way to simply specify a wildcard mask in the .csproj file, such as "include=*.cs" instead of listing each file separately. I may be wrong though.