Lack of Designer/Code assistance from VS with samples

[michael-hawker]

I noticed we're getting proper tooling support in the Test shared project, but not in the sample one.

I think this is because we're using a shared project for the tests, but we're using some sort of assembly for the samples?

We should investigate switching to use the same shared project approach for the samples that we're doing with the tests.

This should hopefully give us better tooling support when working with samples which will be important.

You can see the difference by opening up an Experiment (or the ProjectTemplate) and opening up a XAML file in the test project (where you should see the platform UWP/WinAppSDK drop-down in the top-left) and where you should get intellisense in the XAML. If by contrast you open up a XAML file in the sample project, you get neither and just the XML tree in the dropdown or 'miscellaneous files'.

@Arlodotexe have you see this too? I think this is an artifact of just when we set things up initially vs. what we learned later?

[Arlodotexe]

This is a side effect of how Visual Studio treats XAML in multitargeted projects. None of our shared projects are multitargeted, instead the heads are only one of the many possible target frameworks and the shared project gives it the files to work with.

This is something Uno has been working with Visual Studio on fixing for a while now, and if you ask them you'll likely be pointed here. Things improved significantly with Visual Studio 2022, but it's still not perfect yet.

[michael-hawker]

@Arlodotexe I know our source library needs to be multi-targeted, but there's no reason we can't use the better/more stable experience of the shared projects with our samples right? Like we're doing with tests?

It really is difficult to test and develop without the tooling support. I have a feeling this is going to bite us a bit until this is better, but if we can at least make writing samples easier, we can take the pain points for controls.

I also wonder if we could make the source package just look/behave like a UWP project to VS, and then multi-target compile more so on the build step such that VS doesn't get confused? (Though not sure how that'd work with the pre-processor checks.)

Maybe we could also just make it a shared project and handle the output or put the 'package head' in a folder like we do for the other things where it's more hidden? Have a props file in the shared project for any auxiliary properties for the package itself?

[Arlodotexe]

I also wonder if we could make the source package just look/behave like a UWP project to VS, and then multi-target compile more so on the build step such that VS doesn't get confused? Though not sure how that'd work with the pre-processor checks

It would break things in visual studio for sure. If you aren't multitargeting when Visual Studio is opened, you shouldn't be multitargeting at all. If we've learned anything the last few months, doing funky things with MSBuild in an environment as complex as what we have doesn't always work out.

---

Before we start looking at workarounds, we should try to bump the Visual Studio team on this internally to see where they are and what we can expect in the long term.

For the temporary workaround, yes, you could just create a shared project for every sample project, then just hide away the multitargeted project. You could still build it, clean it, reference it, multitarget it, etc., but the files would be in a shared project.

That would be the cleanest and quickest way to do this, but I would pad our estimates here because this kind of change is likely to break things along the way.

[Arlodotexe]

cc @jeromelaban anything you can add to this would be a big help

[Arlodotexe]

Reposting an important discussion from discord:

@Arlodotexe:

To clarify, we would have 1 shared project per 1 sample project.
Otherwise we'll be upending a LOT of infrastructure to implement a workaround

@michael-hawker:

Each experiment still has one sample project, it's just a shared project instead of a multi-targetted project. That's all. It'd work just like the test infrastructure does now. It means you lose a bit of time when running each head as it has to re-compile, but then we get better VS support.

@Arlodotexe:

Okay, but we still need to keep the existing multitargeted sample projects, we're just tacking on a Shared project and moving the files to it
Because if we don't, we'll have to completely throw out the source generators and do them again
as well as any logic for sample discovery outside of source generators (powershell scripts)
This should also be considered a temporary solution, not a permanent one. This is being introduced to work around lack of IDE support from Visual Studio, and restructuring the entirety of Labs to accommodate a workaround that will be fixed in the future isn't a good idea.

@michael-hawker:

Why? We have a source generator that works on Test code? I guess I'm confused on how this would change everything dramatically.
I mean I wouldn't expect a fix in VS for a long time.
I mean maybe there's something else going on, but it was brutal trying to do anything to write samples. It also was just straight-up not working for me, so maybe something else was going on, but I was just trying to add a blank page at the end point when I gave up.

@Arlodotexe:

That's why it's completely fine to add a workaround, just not forever.
If this was something we had done from the very start, like we did with Tests, it would have been fine.
But sample discovery, both powershell and source generators, hinges entirely on the use of actual projects. The logic in the source generators would be the most work to rewrite, because it has a very distinct behavior when running on a sample project vs running on a deployable head.


If we had done this from the very, very start, it actually might have simplified this a little bit. But it would be too much work at this point.
We'd also have to rewrite the "all" solution template, and the logic used to generate it. Managing shared projects in a solution file is much more complex than a normal csproj

We still can (and should) add a workaround that fixes the IDE problems, though, because it's a bit nightmarish, especially if you don't know XAML already. We'll just need 1 shared project per 1 sample project.

@michael-hawker:

I mean we'd just do all the steps all the time as we wouldn't be duplicating the run anymore as it'd just be the head assembly, right?

@Arlodotexe:

If we had done that from the start, yes. This is the very heart of Labs though, so rewriting it means shuffling everything around to accommodate the change.

@michael-hawker:

Is this an alternate proposal you're suggesting? So have multi-targetted project + shared project? Does that really help VS detect the platforms over the multi-targeted project alone?

@Arlodotexe:

This is the only proposal I've been suggesting 😄
I actually hadn't considered that it might inherit problems from the multi-targeted project, but it's definitely worth investigating over the alternative.