[Mono-ue] A call to establish a C# / Mono development and build environment for the plugin

Robert Potter robertbrucepotter at gmail.com
Fri Mar 20 00:52:51 UTC 2015


Disclaimer: I speak for neither Epic nor Xamarin, but the info here is all
readily available if you look.

Epic is not really involved in this. This is a Xamarin operation and an
as-yet exploratory one. If your production needs hinge on there being C#
support, I think you will need to look elsewhere for the time being.

That said, there are a few things you might consider:
1) Your desire for binary releases for every is understandable, but for
larger teams/organizations it is immensely helpful to have the tools build
as just part of your normal process. Especially when it comes time to prep
to go live, you want the ability to lock down a version but still take bug
fixes from downstream (not to mention any changes you may want to make to
better support your usage). If building the tools and distributing them to
your team (via source control like Perforce or a local CDN... don't use
DVCS like git or hg for large binary content) is just part of your normal
process, then it won't be a potentially crippling distraction in the
critical time of your project.
2) There are things C# does not do well, especially in realtime
applications (though I don't think you've specified, this doesn't sound
like a "game" project, but this still applies in general for RTA). C/C++ is
difficult to avoid at a certain level, since some of the hoops you have to
go through to get the same behavior in C# (say, fixed structured arrays);
not to mention, the runtime optimizers are still less than ideal
(especially the Mono-Unity version. Holy hell, it's terrible). It's hard to
say whether it would come to that since I don't really know your project,
but I quite often find a moment where I really want to be explicit about
what the computer should do and C# is not the language for that (arguably,
neither is C++).
I still like C#, and I am watching this project closely, but I don't think
you are going to get what you want here.

-Robert

PS: not sure what build issues you are having, but I found the process
pretty straight forward if you follow the directions. A few things though:
1) Make sure you have all of the prereqs (don't skip things like the DX
Runtime version it specfies... it can give you seemingly unrelated build
errors) installed and ready.
2) Build the vanilla version of UE4 first just to ensure that is correct.
It's a mostly turn key process, so other than build time (do it in the
background), it's not much of a hassle.
3) Start with 4.4, since that's the version that it is targeting while the
plugin stabilizes. You can get it working with the later versions, but I
would hold off on that until you get it working with 4.4 (easier to get
support).


On Thu, Mar 19, 2015 at 4:48 PM, David Ford <davidfordaus at gmail.com> wrote:

> As mentioned - we have tens of thousands of lines of C#, and a small
> number of lines in JavaScript.  In short:
>
>
>    - We have developers that need to know one language - C#
>    - The rest of our product is in a single language
>    - C++ itself is notoriously painful (though I know it reasonably well
>    myself - I find it far easier to code in C# with Linq, reflection,
>    automatic GC, etc etc)
>
> In short: rather than either re-skill a developer to C++, or fragment the
> team, or outsource the work, or any one of a myriad issues surrounding
> supporting C++ - we're using C# unless a compelling case can be made to
> support multiple languages.  As it is we're using C# with a number of
> additional frameworks (eg Postsharp, etc) - so it's a non-trivial C#
> environment in any case.
>
> This should be just a plugin - built by Xamarin or Unreal / Epic.  This
> would install in seconds. Ryan Burnham's comment seems to indicate the
> issues he's found using the existing practice of "compile your own".
>
> In addition to the rebuild problem - the statements around the fact that
> the plugin isn't "production ready" after many months of apparently zero
> development does not fill me with any sense that it's a viable option
> long-term, and could be killed at any point.
>
> Epic / Unreal - if you're listening : I will be blogging about our
> experiences with the C# environment.   My most honest and best advice is
> this:
>
>
>    - Finish it - not all features need to be supported, but core ones do
>    need to be
>    - Include C# / Mono as part of your software build process - which
>    will make it part of your normal dev cycle, and will disappear as a problem
>    - Distribute it with the product out of the box
>    - Trumpet it across the C# development threads
>
> Right now it's a failed feature launch.  It indicates that it's easy to
> use - but the reality is far from this, and is largely full of frustration.
>
>
>
>
> On 20 March 2015 at 10:23, Eugene Tchoukhrov <ujen at vicogamestudio.com>
> wrote:
>
>> Hi David,
>>
>>
>>
>> I’m not with Xamarin nor Epic.
>>
>>
>>
>> Just for my curiosity, what are the reasons you and your team are tied to
>> C#? I moved our team over to UE4 and C++ a couple years ago and we have not
>> looked back. It has been a great experience working with C++ and UE4.
>>
>>
>>
>> Kind regards,
>>
>> Eugene
>>
>>
>>
>> PS, you don’t have to respond, but I’m simply curious.
>>
>>
>>
>> *From:* mono-ue-bounces at lists.ximian.com [mailto:
>> mono-ue-bounces at lists.ximian.com] *On Behalf Of *David Ford
>> *Sent:* Thursday, March 19, 2015 2:58 PM
>> *To:* Ali Scissons
>> *Cc:* mono-ue at lists.ximian.com
>> *Subject:* Re: [Mono-ue] A call to establish a C# / Mono development and
>> build environment for the plugin
>>
>>
>>
>> I think my request still stands.  There is very little (if any) benefit
>> to having each individual developer compiling on their own.  Few (if any)
>> Unreal downloadable examples appear to use 4.4.
>>
>>
>>
>> I am re-tasking our developers to Unity as of this morning, and halting
>> Unreal development entirely.   We may return to Unreal at some point, but
>> will review the decision to support two engines in detail before committing
>> to that effort.
>>
>>
>>
>> If there are someone within Xamarin / Unreal that this email can be
>> forwarded to - I'd appreciate it.  We're expending effort developing
>> products, not wasting time recompiling (with compilation errors, as it
>> turns out) non-production grade toolchains.
>>
>>
>>
>> Regards
>>
>>
>>
>> David
>>
>>
>>
>>
>>
>> On 20 March 2015 at 03:24, Ali Scissons <ali.scissons at gmail.com> wrote:
>>
>> The plugin isn't complete and not ready for production use, not to
>> mention the plugin requires changes with UE4 itself (thus the patches).
>> However, not everyone is required to build UE4/plugin from scratch. Once it
>> is built, you should be able to redistribute it to your other developers
>> and only have them setup with C# related tools like Xamarin Studio and it's
>> plugin.
>>
>>
>> Ali Scissons
>>
>>
>>
>> On Thu, Mar 19, 2015 at 7:34 AM, David Ford <davidfordaus at gmail.com>
>> wrote:
>>
>> I'm somewhat confused as to why each developer wishing to use C# "must"
>> recompile from source.  As far as I can see there's nothing compelling
>> within the Mono code that requires that each developer should rebuild for
>> their own specific machine or environment.
>>
>>
>>
>> Can I suggest that the better (best) approach be that a virtualised build
>> environment be established within Xamarin or Unreal / Epic, and that a
>> single developer be tasked with updating the Mono plugin on each release of
>> the game engine (presumably the API's don't change between patches to point
>> releases - eg 4.7 + patch will be compatible with the plugin if 4.7 raw is
>> compatible.  This developer wouldn't be full time, but may perhaps spend a
>> day each month (or less, assuming straightforward compatibility between
>> releases).
>>
>>
>>
>> At this stage there is potentially a vast amount of wasted effort having
>> every C# developer establishing a full Mono build environment and toolchain
>> for C#, when in fact most developers (including myself) simply want to
>> download the Mono plugin and add it to the UDK, then add our own C#
>> assemblies.
>>
>>
>>
>> We currently have one developer spending several days simply getting a
>> Mono C# plugin environment to run, when in reality a pre-built Mono plugin
>> would have removed all of that needless effort, and reduced the time to
>> hours at most.
>>
>>
>>
>> We would prefer to use Unreal rather than Unity, however at this stage I
>> may pull our Unreal development completely and switch our (early phase)
>> project to the Unity platform based solely on the lack of a simplified
>> development toolchain with C# / Mono.
>>
>>
>>
>> Note that all the other code for our project (20 + C## projects, tens of
>> thousands of lines of code) are C#, and I see no reason to add a small
>> amount of C++ purely to support Unreal, and based solely on the fact that
>> recompiling the Mono C# plugin for each UDK release is non-core effort.
>>
>>
>>
>> Best regards
>>
>> David Ford
>> 0421 659 552
>>
>>
>>
>> _______________________________________________
>> Mono-ue mailing list
>> Mono-ue at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-ue
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Best regards
>>
>> David Ford
>> 0421 659 552
>>
>
>
>
> --
> Best regards
>
> David Ford
> 0421 659 552
>
>
> _______________________________________________
> Mono-ue mailing list
> Mono-ue at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-ue
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-ue/attachments/20150319/101be7b6/attachment-0001.html>


More information about the Mono-ue mailing list