Windows 10 Free Upgrade: More details, Windows RT excluded

The Windows 10 site displays a tiny disclaimer giving more details about the upgrade.

It is our intent that most of these devices will qualify, but some hardware/software requirements apply and feature availability may vary by device. Devices must be connected to the internet and have Windows Update enabled. ISP fees may apply. Windows 7 SP1 and Windows 8.1 Update required. Some editions are excluded: Windows 7 Enterprise, Windows 8/8.1 Enterprise, and Windows RT/RT 8.1. Active Software Assurance customers in volume licensing have the benefit to upgrade to Windows 10 Enterprise outside of this offer. We will be sharing more information and additional offer terms in coming months.

This means the following:

  • The upgrade will be done via Windows Update
  • Windows 8 customers need to *somehow* upgrade to Windows 8.1 ( getting past those store upgrade issues)
  • Enterprise versions are excluded. (This is not a problem since most will have a MSDN or volume license)
  • The most important Windows RT and Windows RT 8.1 are excluded.
    • No Windows 10 free upgrade for Surface RT and Surface 2 customers. (They could buy Windows 10 for ARM, if it is announced)

Source: http://windows.microsoft.com/en-us/windows-10/about (direct link: https://winpreview.catalysis.com/registration.aspx?hfid=WRF0&loc=en-US#disclaimer)

Related News

Universal App with SQLite – Part 2

This post is from Nicolò Carandini‘s blog post Universal App with SQLite – Part 2

In this series of posts, I’ll describe how to build a SQLite Test app that will run on Windows Runtime 8.1 Devices (Windows 8.1 and Windows Phone 8.1).

On the first post, I briefly introduced the new “Universal App” Visual Studio project type, and explained how to add SQLite to the project.

On this second post, we will see how to use the Universal App project type to avoid unnecessary duplication of code by sharing the things that remain the same for both Windows Store app and Windows Phone Store app, and how to take advantage of SQLite to manage locally stored data.

On the first post we’ve created a Universal Windows App (this is the official term for Apps built using the shared project tooling that target both Windows and Windows Phone ), with all the right references to the SQLite library.

To help us hiding all the intricacies of calling the SQLite APIs, now we will add the sqlite-net library on both Windows and Windows Phone projects, using NuGet:

As a result, we will have two copies of the two files “SQLite.cs” and “SQLiteAsync.cs”, one in the Windows project and one in the Windows Phone project:

To avoid unnecessary duplication, let’s start using the shared project:

  1. Move one copy of “SQLite.cs” and “SQLiteAsync.cs” files to the Shared project
  2. Delete the other copy.

At the end, this will be the new outcome:

Using sqlite-net is very simple and there are many posts describing how to use it, like Using SQLite in your Windows 8 Metro style applications by Matteo Pagani.

Problem is that some of them are a bit dated and something on the sqlite-net library has changed from then, so it’s better to repeat here the basic operations available:

Create / Open a database

To open a database named “People.db” (will be created if nonexistent):

By default, the sqlite-net library will create the database file on:

To check for the existence of the database file:

Create a table

We start defining the class that represent the table row:

As you can see, it’s possible to decorate the class and the properties with attributes defined in the sqlite-net library, in almost the same way we are used to do with DataAnnotation and EF. Here is the full list:

Class attribute:

  • [Table(Name)]

Property attributes:

  • [AutoIncrement]
  • [PrimaryKey]
  • [Column(Name)]
  • [Indexed] | [Indexed(string name, int order)]
  • [Unique]
  • [Ignore]
  • [MaxLength(int length)]
  • [Collation(string name)]
  • [NotNull]

Because the User class is part of our model that will be used by both the Windows and Windows Store app, the right place to create it is on a Model folder located into the shared project:

Now that we have defined the class that correspond to the table row, we can create the table, using the database connection:


The method will check for the existence of the table in the SQLite file and if not found it will create it. Moreover, if the class that represent the table row has changed, the method will try to update the SQLite table (actually, only the adding of new columns is supported).

It worth noting that the method will not destroy an existent table, so it can be redone without previously checking for the existence of the table.

Add a record to a table

This is super easy:

Add records to a table

Any IEnumerable collection can be added to the table (the IEnumerable item type must obviously be the same of the table creation one):

Retrieve records

We can query directly a table object using Linq:

or using the connection query method:

The SQL command can contain parameters:

Update records

Once retrieved, the object representing the table row can be easily modified at model level and persisted at database level:

Delete records

To delete a table row:

Drop a table

Deleting a table is also super easy:

You can download the demo solution on my OneDrive: http://1drv.ms/1kQ9sP0

This conclude my second post on how to use the Universal App project type to avoid unnecessary duplication of code by sharing the things that remain the same for both Windows Store app and Windows Phone Store app, and how to take advantage of SQLite to manage locally stored data.

Universal App with SQLite – Part 1

This post is from ‘s blog post Universal App with SQLite – Part 1

In this series of posts, I’ll describe how to build a SQLite Test app that will run on Windows Runtime 8.1 Devices (Windows 8.1 and Windows Phone 8.1).

On this first post, I will briefly introduce the new “Universal Apps” Visual Studio project type, and explain how to add SQLite to the project.

Windows Phone 8.1 is finally out (as a Developer Preview) and the convergence of platforms brought us a new type of Visual Studio project type: the “Universal Apps”:

The idea is simple, yet elegant and powerful. Now that Windows Phone has joined the party, we can have a single project folder that contains three projects, one for the Windows App, one for the Windows Phone Store App and one for all the things that we want to be shared by both the previous projects:

This way we can keep the things we need to do differently for Windows Store app and Windows Phone Store app (typically the UI) and put all the rest in the shared part without any unneeded duplication.

Ok, enough talking, so let’s move on and start creating the app.

First, you need to have Visual Studio 2013 and install the Visual Studio 2013 Update 2 Release Candidate.

Then you can create a new blank Universal App and call it “SQLiteTest”:

Now that you have your wonderful three-part project, you need to add SQLite. Actually, the only way to do so is via SDK extensions of Visual Studio and you need to add two of them, one for Windows Store app and one for Windows Phone Store app.

The first extension is available as a VSIX package built by the official SQLite Development Team from the Visual Studio Extensions Gallery:

It’s worth noting that the current version (3.8.4.3) has a flaw in the package metadata that prevent it to show up in the Visual Studio 2013 “Tools | Extensions and Updates” page. You need to go to the web page, download and install the VSIX package by yourself:

You can directly open it while downloading, authorize installation and click install when ready:

The second extension is also available as a VSIX package but is a preview version built by Tim Heuer of Microsoft as temporary workaround while the official package is still not available (I’ll update this post when it will be available).  now available from the SQLite team!

Same as before, you can directly open it while downloading, authorize installation and click install when ready:

To double check that everything is all right, you can open Visual Studio 2013 “Tools | Extensions and Updates” and look for installed SDKs:

Once you have downloaded and installed both VSIX packages, you are finally ready to add the SQLite references to your Universal App project.

First, right click to the References container of the SQLite.Test.Windows (Windows 8.1) project:

Then add the reference to the “SQLite for Windows Runtime (Windows 8.1)” library:

Second, right click to the References container of the “SQLite.Test.WindowsPhone (Windows Phone 8.1)” project:

Then add the reference to the “SQLite for Windows Runtime (Windows Phone 8.1)” library:

When done, you can see that the proper references to SQLite and Visual C++ 2013 Runtime have been added to respective projects:

Problem is, as you may have already noticed, that the references show a warning sign. If you try to build the solution, you will receive the same error for each of the four added references (below I’ve reported the one related to the SDK “SQLite.WinRT81, Version=3.8.4.3″):

“The processor architecture of the project being built “Any CPU” is not supported by the referenced SDK “SQLite.WinRT81, Version=3.8.4.3″. Please consider changing the targeted processor architecture of your project (in Visual Studio this can be done through the Configuration Manager) to one of the architectures supported by the SDK: “x86, x64, ARM”.

Don’t panic! As better explained in the Tim Heuer’s blog, these things are platform-specific and/or native and have dependencies on various native compiler/linker options or have been compiled in such a way that are different for the Phone device versus a tablet device.

The easy solution is to open the Configuration Manager and set the platform to x86 on both projects for Debug and Release configuration. Do not chose x64 or the XAML designer will not be able to show the UI.

This will not prevent you to create the different platform version to be deployed on the store, because when ready you will use the “Create App Packages…” command:

For the Windows Store app:

and the Windows Phone Store app:

Then will be the Store that automagically will deploy the right package for the device platform of the user that is downloading our beloved app from the store.

This conclude my first post on how to create (and successfully build) a Universal App project with SQLite.

On next post, we will see how to use the Universal App project type to avoid unnecessary duplication of code by sharing the things that remain the same for both Windows Store app and Windows Phone Store app, and how to take advantage of SQLite to manage locally stored data.

Introducing ASP.NET vNext

ASP.NET vNext is:

  • Cloud and server-optimized
  • ASP.NET MVC and Web API have been unified into a single programming model
  • No-compile developer experience
  • Dependency injection out of the box
  • Side by side – deploy the runtime and framework with your application
  • NuGet everything – even the runtime itself
  • All Open Source via the .NET Foundation and takes contributions

Read More… on Scott Hanselman‘s Blog

WordPress for Phone updated

WordPress for Phone has just been updated.

Get the update for all 191 countries from the Windows Phone store

Download Now! http://goo.gl/j6Fzhf

A first look at Windows Phone 8.1 Emulators

With Build 2014 started, we have a new Visual Studio 2013 Update 2 RC available. The update brings with it the new Windows Phone 8.1 Emulators.

Here are some screens from the emulator and my app Maps+ running on the emulator.

The emulator has new features like:

  • Volume up/down
  • Lock screen button
  • Camera button
  • Ability to sign in with Microsoft account to use Cortana

More about the emulator in later posts…

MSDN: Build apps that target Windows and Windows Phone 8.1 by using Visual Studio

This is a post from MSDN for the new Universal apps for Windows 8.1 and Windows Phone 8.1. Get the latest resources from http://dev.windows.com

You can build an app for Windows and Windows Phone 8.1 at the same time, and share code, user controls, styles, strings and other assets between them. This reduces the expense associated with building and maintaining an app for each type of device.

If you already have a Windows Store app, you can easily add support for a Windows Phone Store app. Similarly, if you start by creating a Windows Phone app, you can easily add support for a Windows Store app.

 

Develop an app that targets Windows and Windows Phone 8.1

To get started, pick a Universal project template in the New Project dialog box.

This image shows the universal project templates that are currently available for C#. Visual C++ has a similar set of Universal App templates..

Universal Project templates in Visual Studio

When you select a template and create a solution, three projects appear in Solution Explorer: a Windows Phone project, a project, and a Shared project.

This image shows a solution that appears when you choose a Blank App project template.

Converged project in Solution Explorer

  • The Windows Store project contains XAML pages and code that target Windows.
  • The Windows Phone project contains XAML pages and code that target Windows Phone 8.1.
  • The Shared project is a container for code that runs on both platforms. The contents of the Shared project are automatically included in both the Windows Phone and the Windows Store projects. There is no build output from the Shared project itself.

When you build the solution, Microsoft Visual Studio builds a Windows Phone Store app and a Windows Store app. When you run the solution, for example by pressing F5, the project that is set as the startup project is the one that runs. To set either the phone or Windows project as startup project, right click on the project node in Solution Explorer and choose Set as Startup Project. The project that you choose shows in bold in Solution Explorer. In the previous image, App1.Windows (Windows 8.1) is the startup project.

When the Windows project is the startup project, the Debug target dropdown displays options for the Windows Simulator or Local Machine. When the Phone project is the startup project, the dropdown displays options for Device as well as various phone emulators. In a C++ phone project, you must manually set the build configuration to the ARM platform in order to see the Device option and deploy the app to a physical device. The Win32 configuration is used for the phone emulators only. Set the platform by navigating to Project | Properties | Configuration Manager | Platform.

Get started writing a converged app

Consider starting with the template named Hub App (Universal Apps) instead of a Blank App. The Hub App template creates an app that has three pages. (Hub is the equivalent of Panorama in previous versions of Windows Phone.) You can find the Hub App template under the Universal Apps category. To read more about the Hub App project template, see Visual Studio templates.

This image shows the Hub App project template selected in the New Project dialog box.

Hub App template in Visual Studio

Write cross-platform code in the Shared project

In the Shared project, you typically write code that runs on both platforms. You can also use the #ifdef directive to isolate sections of code that are platform-specific. The constants WINDOWS_APP and WINDOWS_PHONE_APP are conveniently predefined for you. (In C++ use this directive: #if WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP)...#endif.

You can use drag-and-drop to move files from one of the platform-specific projects to the Shared project or vice versa to change the scope of the code.

Note

Platform context in the code editor

When you’re writing code in the Shared project, the Visual Studio code editor uses a context that targets one platform or the other. In C#, the Intellisense that you see as you write code is specific to the context of the code editor – that is, specific to Windows or to Windows Phone 8.1. In C++, the context (and not the startup project) determines whether the code inside the #if WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP directive is greyed out or not.

If you use an API in shared code that’s not supported on both platforms, an error message will identify this API when you build the project. You can confirm that you’re using cross-platform APIs, however, without building the project. Switch the editor context in the drop-down list to the other platform to see squiggly lines under APIs that are not supported on that platform. Then isolate those APIs by using the #ifdef directive.

This image shows the context chooser drop-down list in the Visual Studio code editor.

Context switcher drop-down list in the code editor

Add support for a Windows or Windows Phone 8.1

If you’ve published a Windows Store app already, it’s very easy to reuse some of the code and publish a version of your app for Windows Phone 8.1. Similarly, if you started by creating a Windows Phone 8.1 app, you can modify your solution to build for Windows desktops and tablets as well. To add support for one type of device or another, open the shortcut menu for the project and choose either the Add Windows Phone 8.1 or Add Windows 8.1

Adding a Windows Phone 8.1 project

Depending on which type of app your adding support for, Visual Studio adds Windows Phone 8.1 or Windows Store project to your solution. Visual Studio also adds a Shared project as well. This image shows a project after a Windows Phone project has been added.

Phone project added to solution.

Move files into the Shared project

You can move any code that you want to share between apps to the Shared project. For example, if you created your app by using a Visual Studio template, consider moving the Common, DataModel and Strings folder into the Shared project. You can even move App.xaml into the Shared project. More on that later in this topic. This image shows a solution after files and folders have been moved into the Shared project.

Files moved into the shared project

You’ll probably receive some compiler errors in the code that you’ve shared. In many cases, you can resolve the errors adding assembly references to the new app project. (In C++, if both projects depend on a LIB or DLL, you have to specify it separately in each project.) For example, if code refers to the JsonConvert type in the Newtonsoft.json assembly, that code might have compiled before you moved it into the Shared folder because your Windows Store app contained a reference to the that assembly. Now that you’ve moved that code into the Shared project, you’ll have to also add the Newtonsoft.json assembly to the Windows Phone project. This image shows assemblies added to both projects.

Assembly references added to both projects

If your shared code uses API’s that are specific to Windows, use the #ifdef directive to isolate that section of code. You can isolate sections of Windows-specific code by using the WINDOWS_APP constant. Apply the WINDOWS_PHONE_APP constant to isolate sections of code specific to Windows Phone 8.1. The next section shows an example of how to apply these constants, and the analgous constants used in C++

Note  Moving files from one project to another does not physically move them in the file system. In a C++ project, this means that if you drag files to another project, you might have to adjust header file paths in your #include directives.

Share the App.xaml

In a brand new Universal app, Visual Studio places App.xaml into the Shared project. You can do this with your converted solution, but you’ll have to set the Build Action property of the page to ApplicationDefinition.

  1. In Solution Explorer, in the Shared project, select the App.xaml file.
  2. Select View > Properties Window.
  3. In the Properties window, in Build Action drop-down list, select ApplicationDefinition.

You’ll also have to decide how you want to handle code that opens the first page of your app. For example, the App.xaml page of a solution might start a page named HubPage as shown below:

if (!rootFrame.Navigate(typeof(HubPage)))
{
    throw new Exception(“Failed to create initial page”);
}

For this code to compile, both projects must contain a page named HubPage. If you would rather use a page by a different name, you’ll have to add #ifdef directives as shown below:

#if WINDOWS_APP
                if (!rootFrame.Navigate(typeof(HubPage)))
#endif
#if WINDOWS_PHONE_APP
                if (!rootFrame.Navigate(typeof(WindowsPhoneStartPage)))
#endif
                {
                    throw new Exception("Failed to create initial page");
                }


Finally, ensure that any styles defined in your App.xaml file use resources that are available in both types of apps. Otherwise, move those style definitions into the Windows Store or Windows Phone project

Source: MSDN

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: