Remove working directory change

[Scellow]

This isn't really needed, it change the default and expected behavior of a .net core application, they have their working directory set to the project folder

[Scellow]

And it seems to not be safe in some cases

https://github.com/dotnet/corert/issues/5467

I think you added that because of how you handle asset hotreloading, there must be a better way of doing it

[tlgkccampbell]

I think I fell back to this because there was some platform on which the AppContext.BaseDirectory API was giving strange results, but I don't actually remember for sure.

You're probably correct that Ultraviolet should try to follow .NET Core's conventions here -- figuring out exactly how to do that has been an ongoing process -- but doing this correctly is going to require more than just deleting this line of code. For one thing, Ultraviolet uses Assembly.Location in several places, but also I'm going to have to update pretty much all of the sample projects because they're not actually putting their content files in the project directory right now.

[Scellow]

I'll check the whole .net core project and test everything, i'll try to figure out what's the best solution for this

Concerning the samples, i think it'd be nice to have them in a single project, each sample in a single screen, this will be easier to manage i think

[tlgkccampbell]

I've looked at this some more today and I'm not convinced that it's bad practice to change the working directory -- see dotnet/project-system#2239. It appears that they're leaving the decision of what the working directory should be up to each individual framework, and changing it to the app directory provides the most consistency with Ultraviolet's other supported platforms. The problem was that I was using the wrong (old) API to do it.

I'm working on a branch which removes as many references to Assembly.Location as possible. I vaguely remember that there was some circumstance in which AppContext.BaseDirectory was returning null when I first tried to implement this, so I'm going to need to do smoke testing on every supported platform before anything gets merged, which may take a few days.

I'm also adding a check which disables support for runtime compilation of binding expressions when using .NET Native, since it's very likely to break anyway without the managed assemblies for your application being present. You'll need to continue to produce a non-native version of the app in order to perform this compilation.

In the past, NGEN/.NET Native scenarios are not something I've ever invested any time in supporting, so please continue to submit any bugs you encounter around this.

[Scellow]

I forgot to report my progress on this

I'm able to compile it using CoreRT, but there is one problem with Texture loading

https://github.com/dotnet/corert/issues/5731

Solution would be to get rid of the System.Drawing.Common dependency and use something else

MonoGame is now using StbSharp, UV could probably use that too:

https://github.com/MonoGame/MonoGame/tree/develop/MonoGame.Framework/Utilities/Imaging

https://github.com/rds1983/StbSharp

In case you want to try CoreRT too, you'll need this rd.xml file

<Directives>
    <Application>
        <Assembly Name="Ultraviolet">
            <Type Name="Ultraviolet.IUltravioletFactoryInitializer" Dynamic="Required All" />
            <Type Name="Ultraviolet.UltravioletFactoryInitializer" Dynamic="Required All" />
            <Type Name="Ultraviolet.Platform.ClipboardService" Dynamic="Required All" />
            <Type Name="Ultraviolet.Platform.ClipboardServiceFactory" Dynamic="Required All" />
        </Assembly>
        <Assembly Name="Ultraviolet.OpenGL">
            <Type Name="Ultraviolet.OpenGL.OpenGLUltravioletGraphicsFactoryInitializer" Dynamic="Required All" />
        </Assembly>
        <Assembly Name="Ultraviolet.SDL2">
            <Type Name="Ultraviolet.SDL2.Platform.SDL2ClipboardService" Dynamic="Required All" />
            <Type Name="Ultraviolet.SDL2.SDLFactoryInitializer" Dynamic="Required All" />
        </Assembly>
        <Assembly Name="Ultraviolet.BASS">
            <Type Name="Ultraviolet.BASS.BASSUltravioletFactoryInitializer" Dynamic="Required All" />
        </Assembly>
        <Assembly Name="Ultraviolet.Shims.NETCore">
            <Type Name="Ultraviolet.Shims.NETCore.NETCoreFactoryInitializer" Dynamic="Required All" />
        </Assembly>
        <Assembly Name="mscorlib" />
    </Application>
</Directives>

[tlgkccampbell]

System.Drawing has been an ongoing annoyance in the .NET Core implementation. I had been waiting to see if the situation got any better with the changes coming in .NET Core 2.1, but I'll take a look at StbSharp and see if that would be a better solution.