Pages and framework can be SDK version specific

[mahoekst]

Related to #334

[mrlacey]

I like this idea but fear the consequences for testing and the potential number of combinations of options that need considering and testing. X-Ref #325 as we may want to add different things to pages on different versions. Gulp

[ralarcon]

In my opinion we should work as current as possible if not, the combinations would be unmanagable. Other thing is that once generate, developers can change the TargetVersionPlatform to fulfill their demands.

[mdtauk]

What about shared XAML views with a codebehind which uses ifdef to work with both views. It could allow people to transfer from third party Hamburger controls to the Fall Creator's Update version when it comes out, for instance. Could also allow apps to slowly move over to using Acrylic and Fluent design paradigms.

[mrlacey]

I really like this idea. Just keeping "as current as possible" raises a whole number of potential issues.

• Updates to support a new version become a big change. The templates from one day to the next will, potentially, change dramatically. As soon as we move to targeting a new version and using the new SDK we force developers to update and only support end users on the very latest versions.
• By only targeting and testing for the "current" version we risk making it hard for people to go and change to manually adjust the min version. For instance, if the template assumes only the Creators Update SDK and uses things specific to it, then if the developer wants to adjust have TH2 as the minimum they can't without breaking things.
• Lots of feedback I've heard about WTS mentions how useful this will be in enterprise scenarios where they make lots of internal apps. Such environments/organizations are also not the best at keeping all machines updated to the latest/current version. Without the ability to target different versions they can't use the templates provided out of the box.
• Not doing this means it's hard to try out new features of a preview SDK. From a Windows Dev Marketing perspective, saying "We've built a new tool to help you create apps. Go try out the new features of the Fall Creators Update. Oh, but our tool doesn't support it." seems inconsistent at best. To add additional or different versions of features or pages if someone wants to try out a preview SDK seems really useful to me.
• When we add the ability to add pages and features to existing projects, only providing templates that work with the "current" SDK is likely to present issues or be limited in its usefulness as I predict/expect that most apps currently support more than just one SDK.
• "the combinations would become unmanagable" sounds like an unquantified cop-out. That something would be hard to implement (and potentially manage) should not be a deciding factor. It should be a factor that is considered when weighing up priorities and deciding what should be done. Just because something adds more work for the developer is not a good reason not to do it. All things being equal, we should do what's best for the end user and that's the ability to chose what they target. Old versions and previews of future ones.

Would implementation of this feature take a lot more than setting a minimum SDK version in a template config for a page or feature and then loading available templates based on the minimum selected version? Yes, that's a bit more work, but I don't think it's huge. Managing the templates that are included by default becomes as complicated as we allow it based on the templates we include. We'd be in control of this becoming unmanageable. I suspect this would also be very useful to other people when they start building their own templates. The ability to support and test preview SDKs will not only help developers to test new features but will also enable the testing of templates targeting new SDKs before they become the only ones we ship. Yes, it's potentially a lot more combinations to test for but testing is only going to get more complicated anyway. The testing load is an issue that needs to be addressed separately but shouldn't be a barrier to providing useful features that will help developers create better apps.

[mrlacey]

@mdtauk I'd be wary of providing code that includes multiple versions of pages and swapping them out at runtime based on the machine it's running on. This isn't something I'd want to include in code that's supposed to be a good example and demonstrate good practices. The min/target SDK system includes support handling different levels of platform support and I'd want to use this in combination with choosing pages and features for inclusion based on our existing template composition capabilities.

[mdtauk]

@mrlacey I wouldn't have thought it would replace the App level Target and Minimum supported versions, but instead allow pages to target a version, so you can support the new default controls and brushes for the "Current" OS, and use alternatives for previous OSs. Now XAML and XAML.CS can be separate, and that is what Template Studio is generating, you could have an option to generate two XAML Views when adding a page, and the codebehind can have the bools etc needed to allow #IfDef support for having code which is only called from that specific XAML view.

[ralarcon]

Yeah, @mrlacey I see your points and share your vision... what I mean with "as possible" is the way to support broad scenarios as much as possible.

By default we support N and N-1 versions. This means that if the template does not have specific restrictions being developed N-1 (or even N-2) probably will not prevent to work properly under N or N+1 versions (it depends if the newer versions includes breaking changes).

If we think it is interesting to mark the templates with SDK specific version we can implement that is not a problem. My concerns, thinking loud, were more related to the pass of time... considering 2 or 3 of SDKs updates each year will make the templates defined for a certain version will expire soon...

I agree this is something we need to articulate properly with the future in mind and avoiding to have a versioning hell.

[mrlacey]

With a cadence of twice yearly updates, I don't see it getting too wild. The change to Fluent design will, potentially, be a big one but beyond that (and based on the last couple of years) I don't expect there to be a lot of changes with each release, maybe one or two new pages and features to highlight new light up areas of the new SDK. In terms of dropping support for old versions, this should be dictated by the adoption of those older versions. If we get the figures @mahoekst mentions in #334 then we can set a rule that we drop support for a version when it falls below a certain percentage. N&N-1 would be the wrong way to go if it excluded a large proportion of potential users.

[mrlacey]

@mdtauk ifdef directives are handled at compile time and so would be equivalent to having conditional includes in the csproj file. It doesn't help at runtime. Also, I wouldn't be surprised if generating a project which had files that aren't used (compiled) wasn't at least a little confusing for those getting started. (Helping people new to the platform build their first apps is a definite target audience and using advanced compiler features--like conditional csproj includes or defining our own directives somewhere, to only use them elsewhere in code--to work around a support issue doesn't seem like the best idea.)

[touseefbsb]

so where does this stand? @mrlacey I need my app to support anniversary SDK, creators, and creators fall update as well, I need to support these 3 sdks so what way should I be choosing for specific features? do you recommend using ifdef? you said they dont help at runtime, why does that matter? because the OS remains the same version, I guess uwp compiles in the cloud, so when user upgrades the OS version they couldn't see the newer features of the app, because the app was already compiled for that user in previous version? is this the reason that ifdef isnt recommended? Please suggest me what should be used in this scenario, that along with sdk specific features, when user upgrades the OS they can see the newer features for that sdk in the app. should I use ifdef, or should I do some work around by checking api information and writing sdk specific code on each page?

[mrlacey]

IfDef is a compiler instruction and so applies at compile time. If you want to build different versions of your app targeting each SDK then you could go that route but I wouldn't recommend it.

What you'll need to do today is set the Minimum and Target versions for your project and use what is appropriate to your settings and needs in your app. More details at https://docs.microsoft.com/en-us/windows/uwp/updates-and-versions/choose-a-uwp-version

Where this issue (having SDK specific versions of pages and features generated by the tool) stands is still undecided. While it might be desirable for WTS to provide different versions of output it's not yet a priority. I suspect that will change with FCU support though.

[touseefbsb]

yes I know it is currently not supported that is why I asked you for the suggestion, I mean what will be the cons of ifDef? I have never used them before that is why I dont know much about that. I do know about targeting versions, my minimum target is anniversay update, and maximum target is FCU ( insiders sdk ) so uptil now I am supporting these 3 SDKs, the reason I am asking you for best approach because I am planning to use following

1. user has anniversary update : app uses basic features
2. user has creators update : app allows extra features frm creators update sdk as well
3. user is on CFU ( insider or after CFU releases officially ) : app navigates to another shell page which has navigtionMenu control instead of hamburger control of community toolkit, and that page with fluent design navigation menu will host totally different set of pages for the app and all those pages will have elements and features of fluent design.

I am thinking to use composition API to create features near to fluent design as much as possible and use them in anniversay version and creators version of my app, so that they also look 30-40 percent like CFU version of my app. So there might be a pretty good amount of code which will be different in all 3 versions , both in xaml and in c#. so that is why I am asking your suggestion what would be best and efficient approach for this scenario. Also when user updates to next version and next time they open my app they will see the newer version of the app.

I was thinking also to maybe create 3 seprate projects and all of them generated from template studio, so each will have their own shellpage and functionality. and then a fourth shared project ( also generated from template studio ) which will redirect the user to the specific shell page according to the OS version and hence user will be seeing and running the project ( app version ) according to their machine. but my main concern is, will it be efficient? and will it create a bigger size of app package because of more number of projects, files and lot of code? if yes then is there a way to create sdk specifc pages for both the xaml and cs files and all of them have like some shared code as well? e.g : page.anniversay.xaml, page.anniversary.xaml.cs , page.shared.xaml? I hope you get the point.

Thanks a lot for reading this, I just want to make sure I dont set architecture of my app wrong because it will be harder to change afterwards :)

[touseefbsb]

@mrlacey

[mrlacey]

Firstly, please ask all future questions in appropriate places. Yours is a general question about how to build a UWP app that has different behavior when running on different versions of Windows 10. The issue you are commenting on is about having the WTS tool create different pages or pages with different content depending on the SDK versions the app targets. While they're both related to SDK targeting they are very different things.
Your general question would be more appropriate on StackOverflow or the MSDN UWP forum.

Asking this question here is like going to the farm where the eggs you bought were laid and asking the farmer to help you make an omelet.

That said...

Using a #if check to detect the SDK version you're targeting would only be appropriate if you were creating different versions of the app and each one only targeting (min & target versions) a specific SDK.

There are no absolutes but creating multiple projects for different versions of a platform generally, means a lot more work and is harder to maintain over time, especially when new versions of the platform are released. Unless having conditional checks within the code of a single app becomes overwhelming do not break into multiple apps.

Avoid having the code detect the SDK version, instead detect for the specific feature(s) you want to use.

It's ok to have different versions of a page and dynamically choose which to load. Something like:

if(ApiInformation.IsTypePresent("Windows.UI.Xaml.Controls.NavigationView"))
{
    // Navigate to version of page with the FCU NavigationView
}
else
{
    // Navigate to the older version of the page (with the HamburgerMenu)
}

[touseefbsb]

Oh I am really sorry for the inconvinience of asking the question at the wrong place. And thanks for the help :)

[mrlacey]

As per comment on #334 I'm assuming that this isn't something we're ever going to do as it just adds to the compatibility overhead where we have even more combinations of generated items and configurations to code for and test. If definitely off the cards, can we close this?