Minor fixes to the manual
This commit is contained in:
Matteo Pagani
Родитель
d5a42cbdb0
Коммит
1fe0c1af01
|
|
@ -40,14 +40,15 @@
|
|||
<DefaultLanguage>en-US</DefaultLanguage>
|
||||
<PackageCertificateKeyFile>ContosoExpenses.Package_TemporaryKey.pfx</PackageCertificateKeyFile>
|
||||
<EntryPointProjectUniqueName>..\ContosoExpenses\ContosoExpenses.csproj</EntryPointProjectUniqueName>
|
||||
<PackageCertificateThumbprint>5C393BC8CD0E29FA875633F682F40D00C5984CD1</PackageCertificateThumbprint>
|
||||
</PropertyGroup>
|
||||
<ItemGroup>
|
||||
<AppxManifest Include="Package.appxmanifest">
|
||||
<SubType>Designer</SubType>
|
||||
</AppxManifest>
|
||||
<None Include="ContosoExpenses.Package_TemporaryKey.pfx" />
|
||||
</ItemGroup>
|
||||
<ItemGroup>
|
||||
<None Include="ContosoExpenses.Package_TemporaryKey.pfx" />
|
||||
<Content Include="Images\LockScreenLogo.scale-200.png" />
|
||||
<Content Include="Images\Square150x150Logo.scale-200.png" />
|
||||
<Content Include="Images\Square44x44Logo.scale-200.png" />
|
||||
|
|
|
|||
|
|
@ -8,12 +8,12 @@
|
|||
|
||||
<Identity
|
||||
Name="ContosoExpenses"
|
||||
Publisher="CN=AppConsult"
|
||||
Publisher="CN=Contoso"
|
||||
Version="1.0.0.0" />
|
||||
|
||||
<Properties>
|
||||
<DisplayName>Contoso Expenses</DisplayName>
|
||||
<PublisherDisplayName>AppConsult</PublisherDisplayName>
|
||||
<PublisherDisplayName>Contoso</PublisherDisplayName>
|
||||
<Logo>Images\StoreLogo.png</Logo>
|
||||
</Properties>
|
||||
|
||||
|
|
|
|||
|
|
@ -71,9 +71,9 @@ The Universal Windows Platform has been built with security and privacy in mind.
|
|||
Last but not the least, all the investments of the Windows team for developers are focused on the Universal Windows Platform. All the latest features added in Windows 10, like Timeline, Project Rome, Windows Hello, etc. are exposed by the Universal Windows Platform, so that developers can integrate them in their applications.
|
||||
|
||||
#### Desktop Bridge
|
||||
With the introduction of Windows Store apps first and Universal Windows Platform apps later, Microsoft has also introduced a new packaging modell called MSIX (formerly known as AppX), which is very different from the existing deployment models (like MSI). It's completely controlled by the operating system; it can be used to deploy applications not only using traditional approaches, like the web, SSCM, Intune, but it opens up now opportunities like the Microsoft Store / Store for Business / Store for Education.
|
||||
With the introduction of Windows Store apps first and Universal Windows Platform apps later, Microsoft has also introduced a new packaging modell called [MSIX](http://aka.ms/msix) (formerly known as AppX), which is very different from the existing deployment models (like MSI). It's completely controlled by the operating system; it can be used to deploy applications not only using traditional approaches, like the web, SSCM, Intune, but it opens up now opportunities like the Microsoft Store / Store for Business / Store for Education.
|
||||
|
||||
With the release of Windows 10 Anniversary Update, this new format has been expanded to support not only modern applications, but also the existing ones built with traditional Win32 technologies, like WPF, Windows Forms, Java, Electron, etc. **Desktop Bridge** is the name of the technology that has enabled this feature, allowing developers to release their Win32 applications also on the Microsoft Store. Another key feature of Desktop Bridge is that it enables Win32 applications to have an identity, which opens up the opportunity to consume APIs from the Universal Windows Platform.
|
||||
With the release of Windows 10 Anniversary Update, this new format has been expanded to support not only modern applications, but also the existing ones built with traditional Win32 technologies, like WPF, Windows Forms, Java, Electron, etc. [Desktop Bridge](https://developer.microsoft.com/en-us/windows/bridges/desktop) is the name of the technology that has enabled this feature, allowing developers to release their Win32 applications also on the Microsoft Store. Another key feature of Desktop Bridge is that it enables Win32 applications to have an identity, which opens up the opportunity to consume APIs from the Universal Windows Platform.
|
||||
|
||||
When a Win32 application runs packaged with the Desktop Bridge, it's executed inside a lightweight container which helps to improve the security and the reliability of the application. The container enables three features:
|
||||
|
||||
|
|
@ -81,10 +81,10 @@ When a Win32 application runs packaged with the Desktop Bridge, it's executed in
|
|||
- A **virtualized registry**. All the writing operation to the HKEY_CURRENT_USER hive of the registry are stored in a binary file which is unique for each application. This way the application doesn't have the opportunity to interfere with the real registry. And when the user uninstalls the application, the binary file is simply deleted, making sure that no orphan registry keys are left in the system.
|
||||
- A **virtualized file system**. As a best practice in Windows development, all the data generated by an application which is tightly coupled to it (a database, log files, temporary files, etc.) should be saved in the AppData folder, which lives under the user's space. In a packaged application, all the reading and writing operations against the AppData folder are automatically redirected to the local folder, which is unique for an application. This approach helps to keep the system efficient and reliable since, when the user uninstalls the application, the local folder is simply deleted, making sure there are no orphan files left in the system.
|
||||
|
||||
Desktop Bridge plays an important role with XAML Island because, by combining these two technologies, you'll be able to leverage the same time features and user controls of the Universal Windows Platform without rewriting it from scratch with another technology.
|
||||
Desktop Bridge plays an important role with XAML Island because, by combining these two technologies, you'll be able to leverage the same time features and user controls of the Universal Windows Platform without rewriting your application from scratch.
|
||||
|
||||
#### XAML Islands architecture
|
||||
The Windows 10 October 2018 Update with the SDK 17763, enables the scenario of XAML Islands for Desktop applications. That means that Windows 10 now supports hosting UWP controls inside the context of a Win32 Process. The 'magic' is powered by two new system APIs called <a href="https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.hosting.windowsxamlmanager" target="_blank">WindowsXamlManager</a> and <a href="https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.hosting.desktopwindowxamlsource" target="_blank">DesktopWindowXamlSource</a>.
|
||||
The Windows 10 October 2018 Update with the SDK 17763,enables the scenario of XAML Islands for Desktop applications. That means that Windows 10 now supports hosting UWP controls inside the context of a Win32 Process. The 'magic' is powered by two new system APIs called <a href="https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.hosting.windowsxamlmanager" target="_blank">WindowsXamlManager</a> and <a href="https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.hosting.desktopwindowxamlsource" target="_blank">DesktopWindowXamlSource</a>.
|
||||
|
||||
- The **WindowsXamlManager** handles the UWP XAML Framework. As such, the only exposed method is called **InitializeForCurrentThread()**, which takes care of initializing the UWP XAML Framework inside the current thread of a non-Win32 Desktop app, so that you can start adding UWP controls to it.
|
||||
- The **DesktopWindowXamlSource** is the actual instance of your Island content. It has a **Content** property which you can instantiate and set with the control you want to render.
|
||||
|
|
@ -118,7 +118,7 @@ Let's take a look at the msot important benefits of running a desktop applicatio
|
|||
Key investments in .NET Core were made around performances. Startup time is much faster and most of the APIs have been rewritten to be fully optimized. This is true for server side and client side workloads.
|
||||
|
||||
##### Side-by-side support
|
||||
One of the biggest blockers for enterprises to adopt newer versions of the .NET Framework is that it can be installed only at system level and it automatically comes with newer version of Windows. This means that if you have an application which targets .NET Framework 4.5 and you want to update it to take advantage of some of the improvements delivered by .NET Framework 4.7, you are forced to update all the applications (or, at least, to make sure they still run well) at the same time. The reason is that you can't install the .NET Framework 4.7 side-by-side with .NET Framework 4.5, but you have to update the existing 4.5 installation. This isn't a nightmare only for enterprises, but a big blocker also for Microsoft. If you look at the recent history of .NET Framework, you will notice how every upgrade brings mainly fixes and minor improvements. The reason is that, since we need to make sure to maintain backward compatibility, the team can't be agile and evolve the framework with changes that, potentially, can break older apps. Checking new code into the .NET Framework requires a long validation and testing period. You can read some thoughts from the team on this in the following article.
|
||||
One of the biggest blockers for enterprises to adopt newer versions of the .NET Framework is that it can be installed only at system level and it automatically comes with newer version of Windows. This means that if you have an application which targets .NET Framework 4.5 and you want to update it to take advantage of some of the improvements delivered by .NET Framework 4.7, you are forced to update all the applications (or, at least, to make sure they still run well) at the same time. The reason is that you can't install the .NET Framework 4.7 side-by-side with .NET Framework 4.5, but you have to update the existing 4.5 installation. This isn't a nightmare only for enterprises, but a big blocker also for Microsoft. If you look at the recent history of .NET Framework, you will notice how every upgrade brings mainly fixes and minor improvements. The reason is that, since we need to make sure to maintain backward compatibility, the team can't be agile and evolve the framework with changes that, potentially, can break older apps. Checking new code into the .NET Framework requires a long validation and testing period. You can read some thoughts from the team on this [in the following article](https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/).
|
||||
|
||||
.NET Core, instead, can run truly side-by-side, with two different approaches:
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ One of the biggest blockers for enterprises to adopt newer versions of the .NET
|
|||
Additionally, you will be able to leverage many of the benefits of the .NET Core ecosystem, like the opportunity to use the command line tools to create and build your projects or to use the improved .csproj format. In the end, .NET Core 3.0 will bring some specific benefits for desktop development, like a better support to high DPI screens or the opportunity to leverage all the UWP APIs.
|
||||
|
||||
##### Why .NET Core 3 for XAML Islands
|
||||
You should wonder where .NET Core plays a role here. Of course for performance startup and execution of the WPF application: this is the good and immediate gain. The long term advantage is really the fact that this is the migration path for modernizing .NET WPF and Windows Forms applications. All the long-term investments in .NET will be delivered to .NET Core, while the full .NET Framework will focus only on security and feature updates.
|
||||
You should wonder where .NET Core plays a role here. Of course for performance startup and execution of the WPF application: this is the good and immediate gain. The long term advantage is really the fact that this is the migration path for modernizing .NET WPF and Windows Forms applications. All the long-term investments in .NET will be delivered to .NET Core, while the full .NET Framework will focus mainly on security updates and in supporting the latest networking protocols, security standards, and Windows features. You can learn more about the roadmap [here](https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/).
|
||||
|
||||
___
|
||||
## Exercise 1 - Use a 1st party UWP control with XAML Islands
|
||||
|
|
@ -331,7 +331,7 @@ The Universal Windows Platform includes a beautiful and performant control to di
|
|||
### Task 1 - Use the MapControl in the application
|
||||
Like the **InkCanvas** control we have previously added to handle the signature, the **MapControl** is another 1st party control included in the Windows Community Toolkit. As such, we can reuse the same library we have installed in the previous task to add this new control in the detail page of an expense.
|
||||
|
||||
1. If you have completed Exercise 1, you can continue working on the same project. Otherwise, open the folder `C:\XAMLIslandsLab\Lab\Exercise2\01-Start\ContosoExpenses` ; Double click on the **ContosoExpenses.sln** file.
|
||||
1. If you have completed Exercise 1, you can continue working on the same project. Otherwise, open the folder `C:\XAMLIslandsLab\Lab\Exercise2\01-Start\ContosoExpenses`. Double click on the **ContosoExpenses.sln** file.
|
||||
2. We're going to add a new row, right after the full address, with the map control. Look, in the main **Grid** control, for the list of rows inside the **Grid.RowDefinitions** property.
|
||||
3. Add the following code after the 5th row:
|
||||
|
||||
|
|
@ -573,7 +573,7 @@ Let's move on and see how we can request a license and integrate it into our app
|
|||
1. Open a browser on your machine. If you're using the VM setup for this lab, you can use Microsoft Edge.
|
||||
2. Go to the website [https://www.bingmapsportal.com/](https://www.bingmapsportal.com/).
|
||||
3. Press the sign-in button.
|
||||
4. Login with your personal Microsoft Account. It must be a personal account, like @outlook.com. You can't use an Office 365 account. In case you don't have one, feel free to skip the following steps. You will find a license to use later in the exercise.
|
||||
4. Login with your personal Microsoft Account. It must be a personal account, like @outlook.com. You can't use an Office 365 account. In case you don't have one, feel free to skip to step 11. You will find a license to use later in the exercise.
|
||||
5. Once you're logged in the main dashboard, choose **My account -> My keys**.
|
||||
|
||||
|
||||
|
|
@ -596,7 +596,7 @@ Let's move on and see how we can request a license and integrate it into our app
|
|||
|
||||
|
||||
|
||||
10. Press the **Show key** button and copy the that will be displayed.
|
||||
10. Press the **Show key** button and copy the value that will be displayed.
|
||||
11. Now go back to Visual Studio and double click on the **ExpenseDetail.xaml.cs** file in Solution Explorer.
|
||||
12. Look for the constructor of the class, which is the **ExpenseDetail()** method.
|
||||
13. Copy and paste the following code at the end of the method:
|
||||
|
|
@ -1294,7 +1294,7 @@ NuGet packages supports multi-targeting. You can include, in the same package, d
|
|||
|
||||
> Since we don't have anymore a packages.config file, can you guess where the list of NuGet packages gets stored?
|
||||
|
||||
With the new project format, the referenced NuGet packages are stored directly in the .csproj file. You can check by right clicking on the **ContosoExpenses** project in Solution Explorer and choosing **Edit ContosoExpenses.csproj**. You will find some new lines compared to when we have manually edited the file:
|
||||
With the new project format, the referenced NuGet packages are stored directly in the .csproj file. You can check this by right clicking on the **ContosoExpenses** project in Solution Explorer and choosing **Edit ContosoExpenses.csproj**. You will find the following lines added at the end of the file:
|
||||
|
||||
```xml
|
||||
<ItemGroup>
|
||||
|
|
@ -1309,7 +1309,7 @@ With the new project format, the referenced NuGet packages are stored directly i
|
|||
|
||||
|
||||
|
||||
> All these errors have a same cause. What is it?
|
||||
> All these errors are caused by the same issue. What is it?
|
||||
|
||||
Again remember that we deleted all the content of the initial csproj file. We just had the `Bogus` and `LiteDB` NuGet Packages but not the `Microsoft.Toolkit.Wpf.UI.Controls`. There is a reason: got back to the **NuGet: ContosoExpenses** tab and search for `Microsoft.Toolkit.Wpf.UI.Controls`. You will see that this package supports the .NET Framework starting at the version 4.6.2. It does not support yet the .NET Core 3 version.
|
||||
|
||||
|
|
@ -1367,7 +1367,7 @@ The Preview version of .NET Core 3 and Visual Studio 2019 causes the last 6 erro
|
|||
|
||||
This error is our fault because we removed everything in the csproj at the beginning of the exercise.
|
||||
|
||||
> This method for migrating the project to .NET Core 3 is manual because Visual Studio 2019 Preview does not handle yet the migration work for us. When we will release Visual Studio 2019, we can expect to have to do nothing more than clicking on a button to perform the migration.
|
||||
> This method for migrating the project to .NET Core 3 is manual because Visual Studio 2019 Preview does not handle yet the migration work for us. The Visual Studio team is working to make the migration path easier and smoother in the future.
|
||||
|
||||
So to fix this error, we have to reference again the Universal Windows Platform again. This was done in the Exercise 2 Task 3. Here are the same steps:
|
||||
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче