Using the existing MembershipProvider
If you have already an existing Web application and you want to extend it throughout a Windows Phone application you can use the existing System.Web.ApplicationServices for the authentication.

You can do this by creating a new WCF service file and expose the built-in AuthenticationService.

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

In the web.config of the Asp.net Web application you have to add following sections:

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

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

You also need to configure the WCF service itself by using the AspNetCompatibilityRequirements attribute.

[ServiceContract(Namespace = "LieberLieber.Mobile")]
[SilverlightFaultBehavior]
[AspNetCompatibilityRequirements(
              RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class CompanyService

After you have added a service reference to the AuthenticationService.svc and CompanyService.svc you have to enable cookies for the Windows Phone application.

Add following attribute enableHttpCockieContainer and set the value to true.

   <bindings>
       <basicHttpBinding>
           <binding enableHttpCookieContainer="true" name="BasicHttpBinding_AuthenticationService" maxBufferSize="2147483647
               maxReceivedMessageSize="2147483647">
               <security mode="None" />
           </binding>
           <binding enableHttpCookieContainer="true" name="BasicHttpBinding_CompanyService" maxBufferSize="2147483647"
               maxReceivedMessageSize="2147483647">
               <security mode="None" />
           </binding>
       </basicHttpBinding>
   </bindings>

One important notice:

If you need to update the service reference you will get following Microsoft Visual Studio error: “The configuration for the service reference could not be updated due to the following issue: Unrecognized attribute ‘enableHttpCockieContainer’.

To resolve this issue just remove the attribute. Update the service reference and add the attribute again.

Within the Windows Phone application you can now use the AuthenticationService’s method LoginAsync.

    readonly CookieContainer _coockieContainer = new CookieContainer();

    private void Authenticate(string userName,string password)
    {
      var authService = new AuthenticationService.AuthenticationServiceClient();
      authService.CookieContainer = _coockieContainer;
      authService.LoginCompleted += authService_LoginCompleted;
      authService.LoginAsync(userName,password,"",true);
    }

If you make now a method service call, you have to set the same CookieContainer.

    private void GetCompanyName()
    {
      var client = new CompanyServiceClient();
      client.CookieContainer = _coockieContainer;
      client.GetCompanyNameCompleted += client_GetCompanyNameCompleted;
      client.GetCompanyNameAsync();
    }

Authentication without MembershipProvider

If you are using your own authentication method you have to set the authentication cookie by yourself.

   public bool Authenticate(string userName, string password)
   {
     if (userName == "lieberlieber" && password == "ll%123")
     {
      System.Web.Security.FormsAuthentication.SetAuthCookie(userName, false);
      return true;
     }
     return false;
    }

One important thing to remember

If you are using Basic Authentication the username and password are sent in plaintext. That means you should definitely use SSL.

Here you can find a running solution.

See this excellent Blog Post “Could not load file or assembly ‘name’ or one of its dependencies”.

In my Case the trouble was caused by an Third Party .dll compiled for x86, that was referenced by my webapplication.

Man konnte mit dem Prozess-Explorer förmlich sehen, wie eine dll nach der anderen mit grossen Zeitabstand in den Speicher geladen wurde… Irgend etwas schien die Ladezeit stark zu verzögern (Virenscanner?).

Erst nach langer Zeit und Suche bin ich im Google endlich fündig geworden – folgenden Eintrag muss man in einer Config-Datei (app od. web.config) machen (rot hervorgehoben):

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
     <generatePublisherEvidence enabled="false"/>
  </runtime>
</configuration>

Mit dieser Änderung geht das Starten plötzlich wieder im “normalen” Tempo…

Hier die Begründung von Microsoft (http://msdn.microsoft.com/de-de/library/bb629393.aspx):

Die Common Language Runtime (CLR) versucht, die Authenticode-Signatur zur Ladezeit zu überprüfen, damit der Publisher-Beweis für die Assembly erstellt wird. Standardmäßig benötigen die meisten Anwendungen jedoch keinen Publisher-Beweis. Die Standard-CAS-Richtlinie ist nicht auf PublisherMembershipCondition angewiesen. Vermeiden Sie die unnötigen Startkosten, die mit der Prüfung der Herausgebersignatur zusammenhängen, es sei denn, die Anwendung wird auf einem Computer mit benutzerdefinierter CAS-Richtlinie ausgeführt oder muss den Anforderungen von PublisherIdentityPermission in einer nur teilweise vertrauenswürdigen Umgebung genügen. (Forderungen nach Identitätsberechtigungen haben in einer vollständig vertrauenswürdigen Umgebung immer Erfolg.)

Die UI Integration bei der deutschen VS Version scheint zur Zeit noch etwas verbugt zu sein. Wer das ganze selber ausprobieren will, sollte also wenn möglich die englische Version installieren.

Für die MVC Views werden aspx Seiten genutzt. Diese Seiten nutzen im Gegensatz zu Webforms aber keinen form Tag mit dem runat=”server” Attribut. Dass befreit uns dann zwar von dem Viewstate, dafür sind aber auch keine Serversteuerelemente mehr nutzbar. Standardelemente wie Textboxen werden daher über HTML Helper Funktionen eingefügt.

Das Postbackmodell fällt somit weg und es liegt am Entwickler, sich die gesendeten Daten zu merken. ASP.net MVC bietet hier aber gute Unterstützung durch die Modelbinders, welche die Formdaten automatisch an komplexe Models binden kann.

Im Endeffekt handelt es sich aber auch bei MVC um eine ASP.net Anwendung. Entsprechenden kann man diese auch mit Webforms vermischt werden, was recht gut in diesem Artikel erklärt wird.

public sealed class Singleton
{
    static Singleton instance = null;

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
}

Wie es richtig gehört kann man auf der Microsoft Website finden. Ebenfalls eine tolle Erklärung und passende Alternativimplementierungen ohne locks kann man hier finden.

• Die ASP.NET und Windows Forms Chart Controls für .NET Framework 3.5 können hier herunter geladen werden.
  
• Das Microsoft Chart Controls Add-On für Microsoft Visual Studio 2008 gibts hier.
  
• Die Dokumentation und API für die Microsoft Chart Controls könnt ihr hier finden.

Ein paar Beispiele zu den Chart Controls gibs ebenso, sowie das Forum für offene Fragen.

Der einzige logische Anwendungsfall der mir einfällt wäre eine durch xcopy installierbare Webanwendung zu haben die bei einem externen Hoster ohne SQL Server 2005/2008 läuft.

SQL Compact mit xcopy zu deployen ist aber etwas das auch nicht ganz trivial ist – das werde ich mir ein andermal anschauen.

Einfach eine .sdf Datei ins Webprojekt.  Dann eine GridView über den Wizard verbinden.

Und dann geht’s nicht – man bekommt folgende Meldung:

SQL Server Compact is not intended for ASP.NET development.

Ok eigentlich logisch. – Aber dann habe ich zu suchen begonnen und bin auf folgendes gekommen:

Man braucht eine Global.asax in der es eine Zeile geben muss damit der SQL Server Compact auch im IIS läuft.

void Application_Start(object sender, EventArgs e)

{       

   AppDomain.CurrentDomain.SetData(“SQLServerCompactEditionUnderWebHosting”, true);

}

Achtung abhängig von der Version des SQL Ce habe ich unterschiedlich Versionen des keys gefunden, der von mir verwendete ist der richtige für SQL Compact 3.5.

Dazu gibts einen guten Post in einem Blog.

Dann kann man schon auf eine IIS deployen. Allerdings muss in der Web.Config noch der Pfad angepasst werden zur .sdf Datei.