Något som stört mig ett tag är att Firefox tenderar att vara sjukt långsamt när man debuggar Visual Studio-projekt via den inbygga webservern i VS.

En snabb googling gav mig denna tråd på grymma Stack Overflow: http://stackoverflow.com/questions/24959/debugging-asp-net-with-firefox-and-visual-studio-net-very-slow-compared-to-ie

 

Slutsatsen är helt enkelt att man måste inaktivera ipv6 i Firefox, enklaste sättet att göra det är följande:

 

  • Skriv about:config i Firefox adressbar, klicka ja på säkerhetsmeddelandet.
  • Skriv disableIPv6 i filterboxen högst upp och tryck enter. Inställningen "network.dns.disableIPv6" visas.
  • Dubbelklicka på "false" så att värdet ändras till true.

 

När dessa enkla steg är fixade går det tokfort att debugga med Firefox, vilket är supernice eftersom man då kan använda sig av bland annat Firebug.

Jobbar på en lösning som ska dela användare mellan en vanlig ASP.NET WebApplication och en Umbraco-Instans. Till detta skall även användarinfo kunna uppdateras med Batchar som hämtar XML-data och uppdaterar bla adressuppgifter och betalstatus.

 

Jag tittade närmare på två lämpliga lösningar och jag tänkte gå igenom dem här:

1. Användare i Umbraco

Spara användarna i Umbraco och jobba med dem via Umbracos API. Det visade sig att det var krångligt att få igång APIt utanför Umbraco-instansen och att allt arbete med användare och dess egenskaper i Umbraco är databasintensivt.

Ett möjligt alternativ vore att skriva direkt till Umbraco-databasen via webbappen, men alternativet känns inte aktuellt då Umbracos datastruktur är komlex och bör behandlas via dess API.

 

2. Användare i ASP.NET-applikationen

Skapa en skräddarsydd databas där användare sparas och sedan låta båda lösningarna hämta sina användare/roller från denna plats. Det innebär att jag måste skriva en ny MembershipProvider och RoleProvider till Umbraco, även att användarhanteringen i Umbracos backend inte fungerar fullt ut.

Lösningen

Trots arbetet med nya providers och det faktum att backend inte fungerar till 100% så valde jag lösning 2. Att ha full kontroll över användarens data och slippa avancerade databasstrukturer vid batchjobben var mer värdefullt än de få funktioner som inte fungerar i backend pga Custom Providers.