Este artículo se tradujo de forma manual. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original
Información
El tema que ha solicitado se muestra abajo. Sin embargo, este tema no se encuentra en la biblioteca.

.NET Framework Support for Windows Store Apps and Windows Runtime

.NET Framework 4.5

The .NET Framework 4,5 supports a number of software development scenarios with the Windows en tiempo de ejecución. These scenarios fall into three categories:

This topic outlines the support that the .NET Framework provides for all three categories, and describes the scenarios for Windows en tiempo de ejecución Components. The first section includes basic information about the relationship between the .NET Framework and the Windows en tiempo de ejecución, and explains some oddities you might encounter in the Help system and the IDE. The second section discusses scenarios for developing Windows en tiempo de ejecución Components.

The .NET Framework supports the three development scenarios listed earlier by providing .NET para aplicaciones de la Tienda Windows, and by supporting the Windows en tiempo de ejecución itself.

  • .NET for Windows Store apps provides a streamlined view of the .NET Framework class libraries and include only the types and members you can use to create Tienda Windows apps and Windows en tiempo de ejecución Components.

    • When you use Visual Studio (Visual Studio 2012 or later) to develop a Tienda Windows app or a Windows en tiempo de ejecución component, a set of reference assemblies ensures that you see only the relevant types and members.

    • This streamlined API set is simplified further by the removal of features that are duplicated within the .NET Framework or that duplicate Windows en tiempo de ejecución features. For example, it contains only the generic versions of collection types, and the XML document object model is eliminated in favor of the Windows en tiempo de ejecución XML API set.

    • Features that simply wrap the operating system API are also removed, because the Windows en tiempo de ejecución is easy to call from managed code.

    To read more about the .NET para aplicaciones de la Tienda Windows, see the .NET for Windows Store apps overview in the Windows Dev Center. To read about the API selection process, see the .NET for Windows Store apps entry in the .NET blog.

  • The Windows Runtime provides the user interface elements for building Tienda Windows apps, and provides access to operating system features. Like the .NET Framework, the Windows en tiempo de ejecución has metadata that enables the C# and Visual Basic compilers to use the Windows en tiempo de ejecución the way they use the .NET Framework class libraries. The .NET Framework makes it easier to use the Windows en tiempo de ejecución by hiding some differences:

    • Some differences in programming patterns between the .NET Framework and the Windows en tiempo de ejecución, such as the pattern for adding and removing event handlers, are hidden. You simply use the .NET Framework pattern.

    • Some differences in commonly used types (for example, primitive types and collections) are hidden. You simply use the .NET Framework type, as discussed in Differences That Are Visible in the IDE, later in this article.

Nota Nota

For more information about the way the .NET Framework uses Windows metadata to simplify programming with the Windows en tiempo de ejecución, download the CLR and the Windows Runtime white paper from the Windows Dev Center.

Most of the time, .NET Framework support for the Windows en tiempo de ejecución is transparent. The next section discusses some of the apparent differences between managed code and the Windows en tiempo de ejecución.

Hh694558.collapse_all(es-es,VS.110).gifThe .NET Framework and the Windows en tiempo de ejecución Reference Documentation

The Windows and the .NET Framework documentation sets are separate. If you press F1 to display Help on a type or member, reference documentation from the appropriate set is displayed. However, if you browse through the Windows Runtime reference you might encounter examples that seem puzzling:

  • Topics such as the IIterable interface don't have declaration syntax for Visual Basic or C#. Instead, a note appears above the syntax section (in this case, ".NET: This interface appears as System.Collections.Generic.IEnumerable<T>"). This is because the .NET Framework and the Windows en tiempo de ejecución provide similar functionality with different interfaces. In addition, there are behavioral differences: IIterable has a First method instead of a GetEnumerator method to return the enumerator. Instead of forcing you to learn a different way of performing a common task, the .NET Framework supports the Windows en tiempo de ejecución by making your managed code appear to use the type you're familiar with. You won't see the IIterable interface in the IDE, and therefore the only way you'll encounter it in the Windows en tiempo de ejecución reference documentation is by browsing through that documentation directly.

  • The SyndicationFeed constructor documentation illustrates a closely related issue: Its parameter types appear to be different for different languages. For C# and Visual Basic, the parameter types are String and Uri. Again, this is because the .NET Framework has its own String and Uri types, and for such commonly used types it doesn't make sense to force .NET Framework users to learn a different way of doing things. In the IDE, the .NET Framework hides the corresponding Windows en tiempo de ejecución types.

  • In a few cases, such as the Windows.UI.Xaml.GridLength structure, the .NET Framework provides a type with the same name but more functionality. For example, a set of constructor and property topics are associated with GridLength, but they have syntax blocks only for Visual Basic and C# because the members are available only in managed code. In the Windows en tiempo de ejecución, structures have only fields. The Windows en tiempo de ejecución structure requires a helper class, Windows.UI.Xaml.GridLengthHelper, to provide equivalent functionality. You won't see that helper class in the IDE when you're writing managed code.

  • In the IDE, Windows en tiempo de ejecución types appear to derive from Object. They appear to have members inherited from Object, such as Object.ToString. These members operate as they would if the types actually inherited from Object, and Windows en tiempo de ejecución types can be cast to Object. This functionality is part of the support that the .NET Framework provides for the Windows en tiempo de ejecución. However, if you view the types in the Windows en tiempo de ejecución reference documentation, no such members appear. The documentation for these apparent inherited members is provided by the Object reference documentation.

Hh694558.collapse_all(es-es,VS.110).gifDifferences That Are Visible in the IDE

In more advanced programming scenarios, such as using a Windows en tiempo de ejecución component written in C# to provide the application logic for a Tienda Windows app built for Windows using JavaScript, such differences are apparent in the IDE as well as in the documentation. When your component returns an IDictionary<int, string> to JavaScript, and you look at it in the JavaScript debugger, you'll see the methods of IMap<int, string> because JavaScript uses the Windows en tiempo de ejecución type. Some commonly used collection types that appear differently in the two languages are shown in the following table:

Windows en tiempo de ejecución type

Corresponding .NET Framework type

IIterable<T>

IEnumerable<T>

IIterator<T>

IEnumerator<T>

IVector<T>

IList<T>

IVectorView<T>

IReadOnlyList<T>

IMap<K, V>

IDictionary<TKey, TValue>

IMapView<K, V>

IReadOnlyDictionary<TKey, TValue>

IBindableIterable

IEnumerable

IBindableVector

IList

Windows.UI.Xaml.Data.INotifyPropertyChanged

System.ComponentModel.INotifyPropertyChanged

Windows.UI.Xaml.Data.PropertyChangedEventHandler

System.ComponentModel.PropertyChangedEventHandler

Windows.UI.Xaml.Data.PropertyChangedEventArgs

System.ComponentModel.PropertyChangedEventArgs

In the Windows en tiempo de ejecución, IMap<K, V> and IMapView<K, V> are iterated using IKeyValuePair. When you pass them to managed code, they appear as IDictionary<TKey, TValue> and IReadOnlyDictionary<TKey, TValue>, so naturally you use System.Collections.Generic.KeyValuePair<TKey, TValue> to enumerate them.

The way interfaces appear in managed code affects the way types that implement these interfaces appear. For example, the PropertySet class implements IMap<K, V>, which appears in managed code as IDictionary<TKey, TValue>. PropertySet appears as if it implemented IDictionary<TKey, TValue> instead of IMap<K, V>, so in managed code it appears to have an Add method, which behaves like the Add method on .NET Framework dictionaries. It doesn't appear to have an Insert method.

For more information about using the .NET Framework to create a Windows en tiempo de ejecución component, and a walkthrough that shows how to use such a component with JavaScript, see Creating Windows Runtime Components in C# and Visual Basic in the Windows Dev Center.

Hh694558.collapse_all(es-es,VS.110).gifPrimitive Types

To enable the natural use of the Windows en tiempo de ejecución in managed code, .NET Framework primitive types appear instead of Windows en tiempo de ejecución primitive types in your code. In the .NET Framework, primitive types like the Int32 structure have many useful properties and methods, such as the Int32.TryParse method. By contrast, primitive types and structures in the Windows en tiempo de ejecución have only fields. When you use primitives in managed code, they appear to be .NET Framework types, and you can use the properties and methods of the .NET Framework types as you normally would. The following list provides a summary:

  • For the Windows en tiempo de ejecución primitives Int32, Int64, Single, Double, Boolean, String (an immutable collection of Unicode characters), Enum, UInt32, UInt64, and Guid, use the type of the same name in the System namespace.

  • For UInt8, use System.Byte.

  • For Char16, use System.Char.

  • For the IInspectable interface, use System.Object.

  • For HRESULT, use a structure with one System.Int32 member.

As with interface types, the only time you might see evidence of this representation is when your .NET Framework project is a Windows en tiempo de ejecución component that is used by a Tienda Windows app built using JavaScript.

Other basic, commonly used Windows en tiempo de ejecución types that appear in managed code as their .NET Framework equivalents include the Windows.Foundation.DateTime structure, which appears in managed code as the DateTimeOffset structure, and the Windows.Foundation.TimeSpan structure, which appears as the TimeSpan structure.

Hh694558.collapse_all(es-es,VS.110).gifOther Differences

In a few cases, the fact that .NET Framework types appear in your code instead of Windows en tiempo de ejecución types requires action on your part. For example, the Windows.Foundation.Uri class appears as Uri in .NET Framework code. Uri allows a relative URI, but Windows.Foundation.Uri requires an absolute URI. Therefore, when you pass a URI to a Windows en tiempo de ejecución method, you must ensure that it's absolute. (See Pasar un URI a Windows en tiempo de ejecución.)

The scenarios that are supported for managed Windows en tiempo de ejecución Components depend on the following general principles:

  • Windows en tiempo de ejecución Components that are built using the .NET Framework have no apparent differences from other Windows en tiempo de ejecución libraries. For example, if you re-implement a native Windows en tiempo de ejecución component by using managed code, the two components are outwardly indistinguishable. The fact that your component is written in managed code is invisible to the code that uses it, even if that code is itself managed code. However, internally, your component is true managed code and runs on the common language runtime (CLR).

  • Components can contain types that implement application logic, Tienda Windows UI controls, or both.

    Nota Nota

    It's good practice to separate UI elements from application logic. Also, you can't use Tienda Windows UI controls in a Tienda Windows app built for Windows using JavaScript and HTML.

  • A component can be a project within a Visual Studio solution for a Tienda Windows app, or a reusable component that you can add to multiple solutions.

    Nota Nota

    If your component will be used only with C# or Visual Basic, there's no reason to make it a Windows en tiempo de ejecución component. If you make it an ordinary .NET Framework class library instead, you don't have to restrict its public API surface to Windows en tiempo de ejecución types.

  • You can release versions of reusable components by using the Windows en tiempo de ejecución VersionAttribute attribute to identify which types (and which members within a type) were added in different versions.

  • The types in your component can derive from Windows en tiempo de ejecución types. Controls can derive from the primitive control types in the Windows.UI.Xaml.Controls.Primitives namespace or from more finished controls such as Button.

    Nota importante Importante

    Starting with Windows 8 and the .NET Framework 4,5, all public types in a managed Windows en tiempo de ejecución component must be sealed. A type in another Windows en tiempo de ejecución component can't derive from them. If you want to provide polymorphic behavior in your component, you can create an interface and implement it in the polymorphic types.

  • All parameter and return types on the public types in your component must be Windows en tiempo de ejecución types (including the Windows en tiempo de ejecución types that your component defines).

The following sections provide examples of common scenarios.

Hh694558.collapse_all(es-es,VS.110).gifApplication Logic for a Tienda Windows App with JavaScript

When you develop a Tienda Windows app for Windows using JavaScript, you might find that some parts of the application logic perform better in managed code, or are easier to develop. JavaScript can't use .NET Framework class libraries directly, but you can make the class library a .WinMD file. In this scenario, the Windows en tiempo de ejecución component is an integral part of the app, so it doesn't make sense to provide version attributes.

Hh694558.collapse_all(es-es,VS.110).gifReusable Tienda Windows UI Controls

You can package a set of related UI controls in a reusable Windows en tiempo de ejecución component. The component can be marketed on its own or used as an element in the apps you create. In this scenario, it makes sense to use the Windows en tiempo de ejecución VersionAttribute attribute to improve compatibility.

Hh694558.collapse_all(es-es,VS.110).gifReusable Application Logic from Existing .NET Framework Apps

You can package managed code from your existing desktop apps as a standalone Windows en tiempo de ejecución component. This enables you to use the component in Tienda Windows apps built using C++ or JavaScript, as well as in Tienda Windows apps built using C# or Visual Basic. Versioning is an option if there are multiple reuse scenarios for the code.

Title

Description

.NET for Windows Store apps overview

Describes the .NET Framework types and members that you can use to create Tienda Windows apps and Windows en tiempo de ejecución Components. (In the Windows Dev Center.)

Roadmap for Windows Store apps using C# or Visual Basic

Provides key resources to help you get started developing Tienda Windows apps by using C# or Visual Basic, including many Quickstart topics, guidelines, and best practices. (In the Windows Dev Center.)

Developing Windows Store apps (VB/C#/C++ and XAML)

Provides key resources to help you get started developing Tienda Windows apps by using C# or Visual Basic, including many Quickstart topics, guidelines, and best practices. (In the Windows Dev Center.)

Creating Windows Runtime Components in C# and Visual Basic

Describes how to create a Windows en tiempo de ejecución component using the .NET Framework, explains how to use it as part of a Tienda Windows app built for Windows using JavaScript, and describes how to debug the combination with Visual Studio. (In the Windows Dev Center.)

Windows Runtime reference

The reference documentation for the Windows en tiempo de ejecución. (In the Windows Dev Center.)

Pasar un URI a Windows en tiempo de ejecución

Describes an issue that can arise when you pass a URI from managed code to the Windows en tiempo de ejecución, and how to avoid it.

Adiciones de comunidad

Mostrar:
© 2015 Microsoft