Notour's Blog

Petit avant gout du coding for fun de la session Kinect présenter par Niels Freier, et moi même:

La problématique la plus courante, lors de la réalisation d’un éditeur de jeux XNA, est d’afficher le jeu dans l’éditeur. Soit afficher du XNA dans du WPF.

Pour résoudre ce problème plusieurs solutions existent.

- Superposer une fenêtre XNA (après avoir supprimé les bords) avec un canvas. Solution apportée et utilisée par valentin Billote.

- Une autre solution consiste à récupérer les pixels d’une texture XNA dans laquelle on aura préalablement rendu la frame courante. Et de copier ses pixels dans une WriteableBitmap qui sera utilisée comme source d’une image WPF (solution proposée par Niels Freier).

Ses deux solutions fonctionnent mais ont des défauts.

Dans la solution que je vous propose nous allons utiliser une Image (System.Windows.Controls.Image ), une classe Game, une classe D3DImage  et de la réflexion.

En WPF il existe une classe nommée D3DImage. Celle – ci a été créé pour hoster du Direct X dans du WPF. Sachant que WPF et XNA sont deux technologies qui reposent sur la technologie direct X. Une compatibilité entre les deux semble native. Or il n’en est rien. La communication entre ces deux contextes Direct X est assez difficile. Le problème c’est qu’ une D3DImage a besoin d’un pointeur vers une IDirect3DSurface9.  Celle – ci est une surface Direct X utilisée par la carte comme support pour transmette des informations entre le GPU et le CPU. En XNA nous n’avons pas directement accès aux pointeurs manipulés par celui - ci.

Comment récupérer un tel pointeur de XNA ?

    public static class RenderTargetHelper
    {
        #region Fields

        private static readonly MethodInfo m_GetRenderTargetSurface;
        private static readonly FieldInfo m_helper;

        #endregion

        static RenderTargetHelper()
        {
            m_helper = typeof(RenderTarget2D).GetField("helper", BindingFlags.Instance | BindingFlags.NonPublic);
            m_GetRenderTargetSurface = m_helper.FieldType.GetMethod("GetRenderTargetSurface", BindingFlags.Instance | BindingFlags.NonPublic);
        }

        public static IntPtr GetPtr(this RenderTarget2D t)
        {
            Object ptr = m_GetRenderTargetSurface.Invoke(m_helper.GetValue(t), new object[] { CubeMapFace.PositiveY });
            unsafe
            {
                return new IntPtr(Pointer.Unbox(ptr));
            }
        }
    }

Cet Helper permet de récupérer simplement le pointeur de la surface utilisée par un RenderTarget2D. Un RenderTarget2D permet de demander à la carte Graphique de mettre le résultat de ses calculs dans une Texture plutôt que de l’envoyer à l’écran.

Nous avons maintenant le pointeur XNA que nous pouvons exploiter et utiliser pour l’affichage. Comment faire ?

D3DImage m_source = new D3DImage();

unsafe
{
      m_source.Lock();

      m_source.SetBackBuffer(D3DResourceType.IDirect3DSurface9, m_target.GetPtr());
      m_source.AddDirtyRect(new Int32Rect(0, 0, 800, 600));
);

       m_source.Unlock();
}

Tout simplement en settant ce pointeur dans la D3DImage et en spécifiant la zone qui a changé en l’occurrence toute notre surface.

Cette technique permet d’afficher du XNA dans du WPF facilement, sans perte de performance, tout en bénéficiant de la puissance du contrôle image WPF.

Pour vous faciliter encore la vie, je me suis permis de réaliser un contrôle WPF qui va faire tout ce travail pour vous.

Ce contrôle c’est XNAPF. Comment l’utiliser ?

La méthode d’utilisation est simple. Linker la Dll que vous trouverez ici.

Créer une classe qui hérite de XnaImage en spécifiant dans le paramètre template le type de la classe Game à utiliser.

Apres il vous suffit dans Blend ou dans visual studio d’utiliser la classe que vous avez créé comme une image classique WPF.

Pour vous aidez à positionner votre image, celle -ci affichera le logo XNA sur fond bleu, en mode design.

Depuis la sortie de la version 4.0 de .NET qui a été accompagnée d’une version 4 de la CLR, un problème devient récurent le “Mixed Mode Assemblie”

Avec les versions pre – CLR 4.0, la politique était de ne charger qu’une seule version de la CLR pour un processus. Ainsi par défaut tout vos assembly étaient chargés avec la version la plus récente de la CLR que vous possédiez. Ça permet de faire profiter vos anciens codes des améliorations apportées par une version plus récente de la CLR.

Avec la CLR V4 la politique est de charger plusieurs versions de la CLR pour un même processus permettant d’éviter les conflits de version. Par exemple entre du XNA 4.0 qui utilise la CLR v2.0.50727 et WPF 4.0 qui utilise la version 4 de celle – ci.

A l’heure actuelle quand on travaille en mixant les frameworks, on se retrouve avec ce joli message d’erreur :

Mixed mode assembly is built against version ‘v2.0.50727′ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information

La solution à ce problème est assez simple , comme énoncé dans un article précédent, il suffit de de rajouter dans votre fichier App.config(Attention au nom) cette section :

<configuration>
<startup useLegacyV2RuntimeActivationPolicy=”true”>
<supportedRuntime version=”v4.0″/>
</startup>
</configuration>

useLegacyV2RuntimeActivationPolicy : cet attribut précise d’utiliser la politique de load uni – CLR en utilisant le version 2 de la CLR comme contexte principal.

<supportedRuntime version=”v4.0″/> : Cette balise spécifie que la version 4.0 de la CLR doit aussi être chargé

Ce message d’erreur apparaît dans divers contextes, dans visual studio 2010 mais aussi dans Blend 4.0.

Pour ceux qui utilise la suite expression, vous avez dû remarquer que quand vous essayer de faire du “Data Binding” au sein d’un projet regroupant plusieurs versions de la CLR dont la 4.0, de jolis messages d’erreur apparaissent semblables à celui ci-dessus. Pour cela, il suffit de rajouter les balises ci – dessus dans le fichier de configuration du programme, placé à coté du binaire de celui -ci. Par exemple pour Blend le fichier se situe dans “C:\Program Files\Microsoft Expression\Blend 4″ et a pour nom “Blend.exe.config“

Voici un type d’erreur qui arrive souvent quand vous créez des web services

An error occurred while trying to make a request to URI ‘http://localhost:XXXX/AAAAA.svc’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.

Cette erreur est due au fait que votre application tourne sur un port et votre service sur un autre. Pour résoudre ce soucis il vous suffit de créer deux fichiers à la RACINE DE VOTRE WEBSERVICE.

Fichier crossdomain.xml :

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

Fichier clientaccesspolicy.xml :

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Vendredi 9 septembre 2010, un mail annonçant ma nomination au tire de MSP atterrit dans ma boite mail.

Les MSP, soit “Microsoft Student Partener”, sont des étudiants  passionnés par les nouvelles technologies et qui partagent leur connaissance au travers de blogs, de conférences … etc.

Ce titre fût créé en 2001 par microsoft corps, mais il faut attendre 2003 pour voir ce programme atteindre la France. Ce programme comptait, en juillet 2010  environ 2880 membres au travers de 101 pays et régions.

Microsoft Student Partner désigne la relation privilégiée qui se crée entre un étudiant passionné des nouvelles technologies et Microsoft. Le programme MSP récompense des étudiants ayant une maîtrise ou une implication exceptionnelle dans les produits et technologies Microsoft.

Microsoft leur offre :

• une plus grande proximité avec les équipes Microsoft ;
• une aide à l’utilisation des outils et technologies Microsoft ;
• une reconnaissance auprès des professionnels proches de Microsoft ;
• une reconnaissance auprès d’une communauté de passionnés.

Les MSP sont nominés selon leurs participations passées, Microsoft n’attend rien d’eux. Microsoft ne demande qu’un comportement courtois et respectueux.

Le titre de MSP et les bénéfices associés n’engagent nullement à une quelconque participation à l’avenir (mais alors la place de l’étudiant dans le programme peut être discutée), ni à toute autre initiative de Microsoft. La participation à toute autre initiative de Microsoft reste sur une base volontaire. Elle peut s’interrompre à tout moment.

Le seule obligation à laquelle doivent souscrire les MSP est la signature d’une clause relative aux informations confidentielles auxquelles ils pourraient avoir accès dans le cadre de leur nomination (Non Disclosure Agrement)

Tiré de Wikipédia

Beaucoup de personnes cherchent le moyen d’utiliser les sessions à travers une communication entre une application silverlight et un web service WCF.

Vous pouvez désormais le faire facilement grâce à Silverlight 4.0 et à la classe

System.Web.ApplicationServices.AuthenticationService

Voici un exemple vous permettant de voir comment utiliser cette classe et  les sessions.

Commençons par créer le webservice qui vous permettra d’utiliser la classe AuthenticationService. Pour cela créez un fichier texte vierge que vous renommer en AuthenticationService.svc . Ce fichier va nous permettre de créer un webservice sans créer de classe. Dans ce fichier ajouter la ligne suivante :

<%@ ServiceHost Language="C#" Service="System.Web.ApplicationServices.AuthenticationService" %>

Maintenant que vous avez créé votre webservice, nous allons le configurer. Pour cela placer ceci dans votre web.config entre les balises <configuration></configuration>

<system.serviceModel>
  <services>
    <service name="System.Web.ApplicationServices.AuthenticationService"
       behaviorConfiguration="AuthenticationServiceBehaviors">
      <endpoint contract="System.Web.ApplicationServices.AuthenticationService"
          binding="basicHttpBinding" />
    </service>
  </services>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
  <behaviors>
    <serviceBehaviors>
      <behavior name="AuthenticationServiceBehaviors">
        <serviceMetadata httpGetEnabled="true"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
 </system.serviceModel>

Maintenant il faut activer le service avec ceci toujours entre les balises <configuration></configuration>:

<system.web.extensions>
  <scripting>
    <webServices>
      <authenticationService enabled="true" requireSSL="false"/>
    </webServices>
  </scripting>
</system.web.extensions>

Et enfin pour finir :

<system.web>
     <roleManager enabled="true" />
     <authentication mode="Forms" />
     <compilation debug="true" targetFramework="4.0" />
 </system.web>

Maintenant que notre webservice est configuré il faut l’utiliser. Pour cela, très classique, vous l’ajoutez en web référence à votre application silverlight. Vous aurez donc accès à la classe AuthenticationServiceClient qui met à votre disposition des méthodes comme LoginAsync, LogoutAsync, …

La classe AuthenticationService en soi ne vous identifie pas mais elle vous offre un support sur lequel vous pouvez vous greffer pour valider ou non l’identification. Comment, c’est simple il vous suffit simplement de créer un nouvelle item .svc de type “Silverlight-enabled WCF Service” ce qui donne ceci :

namespace TestServices
{
    [ServiceContract(Namespace = "")]
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class ServiceTest
    {
        [OperationContract]
        public void DoWork()
        {
            // Add your operation implementation here
            return;
        }

        // Add more operations here and mark them with [OperationContract]
    }
}

Pour valider l’identification il vous suffit de vous abonner à l’évènement Authentificating et de mettre à ‘true’ ou ‘false’ les propriétés Autenticated et AuthenticationIsComplete pour valider ou non l’identité de l’utilisateur.

namespace TestServices
{
    [ServiceContract(Namespace = "")]
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class ServiceTest
    {
        ServiceTest()
        {
            System.Web.ApplicationServices.AuthenticationService.Authenticating += new EventHandler(AuthenticationService_Authenticating);
        }

        void AuthenticationService_Authenticating(object sender, System.Web.ApplicationServices.AuthenticatingEventArgs e)
        {
            // Check Authentification
            e.Authenticated = true;
            e.AuthenticationIsComplete = true;
        }
        [OperationContract]
        public void DoWork()
        {
            // Add your operation implementation here
            return;
        }

        // Add more operations here and mark them with [OperationContract]
    }
}

Vous avez maintenant un webservice qui vous permet de sécuriser l’accès au service et de stocker des informations propres à l’utilisateur grâce à la classe HttpContext. Afin de savoir si un utilisateur est connecté vous pouvez vérifier cette propriété :

HttpContext.Current.User.Identity.IsAuthenticated

Pour stocker et récupérer des données, vous disposez d’un tableau cle(string)/valeur(objet):

HttpContext.Current.Session.Add("LE NOM DE MA VARIABLE STOCKER", 42);
HttpContext.Current.Session["LE NOM DE MA VARIABLE STOCKER"];

A l’heure actuelle à chaque appel de service un canal de communication est ouvert entre l’application et le webservice. Une nouvelle instance de la classe contenant le service est créée. Afin de d’éviter la création intempestive et pour une bonne gestion des sessions il faut changer les attributs de votre classe. Remplacez les par ceci :

    [ServiceContract(Namespace = "http://asp.net/ApplicationServices/v200")]
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
    [ServiceBehavior(Namespace = "http://asp.net/ApplicationServices/v200", InstanceContextMode = InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Multiple)]

Ces attributs spécifieront au serveur qu’il ne faut créer qu’une seul Instance de cette place par session.