Add Relative Path for the AppShell

[jdevillard]

New Feature Proposal

Add capability to Emulator to load app shell from a relative path to the Pilet.
For now, we can use an app shell using an absolute path.

Description

We can add an attribute to <AppShell /> like ../../path/to/shell

Background

This will allow faster dev/test on local environment.

[FlorianRappl]

For now, we can use an app shell using an absolute path.

That is not true. You can use NuGet package paths. This is also the recommended way.

[jdevillard]

Agree, but the emulator is looking at

    var userProfile = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
    var name = assembly.GetCustomAttribute<Piral.Blazor.Sdk.AppShellAttribute>()!.Name.ToLowerInvariant();
    var path = Path.Combine(userProfile, ".nuget", "packages", name);

So when working on a Solution with Shell and Pilet, we have to pack the nuget and copy it to the %userprofile%/.nuget/packages folder, no ?

If we specify an absolute folder to the /bin of the shell, the emulator seems to work, but maybe this as some side effects.

Why don't allow relative path to the /bin ? or to another folder where nuget package can be found?

[FlorianRappl]

So when working on a Solution with Shell and Pilet, we have to pack the nuget and copy it to the %userprofile%/.nuget/packages folder, no ?

I don't know. Well, at some point you need to pack and distribute; when that is would be up to you. The ideal situation is that a local shell is detected and just used.

If we specify an absolute folder to the /bin of the shell, the emulator seems to work, but maybe this as some side effects.

This is intentional. So this works; absolute paths always work. The problem with relative paths is defining what the path is relative to. You would think it should be the csproj, but we don't know the csproj and we are actually running from some subdirectory of bin, so its quite unclear. A better solution, as mentioned, is to allow referencing local projects; so if you reference MyShell and MyShell is specified in the <AppShell> field you'd actually get this. The benefit of this approach is that we could actually resolve the shell properly and maybe even build it - if it wasn't build.