DependencyProperties och FxCop - ett svar!

Har nu fått ett svar om mitt problem med att följa de guidelines som anges i FxCop när jag använder dependency properties i Workflow Foundation.

Hi Daniel,
Thanks for the feedback. We use FxCop internally on the WF framework, but unfortunately, we must have missed running it on our content (e.g. samples), otherwise we would have picked this up. We are hoping to address this in the next version of WF by making sure that the usage of our OM helps to promote proper .NET coding practice.
Instead of having to add suppressions everywhere in your code, the other option is to disable that particular rule from running. I realize this isn't a great solution, but I thought it may be a reasonable option for you.
Thanks again for reporting this issue.
-- Dave, WF Team

Låter som ett bra och ärligt svar och jag kan med gott samvete arbeta vidare :-)

Nu återstår bara frågan om jag skall designa, dvs med public static readonly eller utan readonly.. då varningen som jag får av fxcop utan readonly är "bara" Microsoft.Usage medan den med readonly är Microsoft.Security (DoNotDeclareReadOnlyMutableReferenceTypes).. trots detta borde readonly vara det mer korrekta sättet att deklarera en dependency property.

Dublin

Det börjar komma fler och fler orter som verkar intressanta, vi har tidigare hört och läst om Oslo men nu är det Dublin som gäller.

Dublin handlar om ett gäng uppdateringar till Windows Server som i första hand berör WCF / WF. Nyckelorden är prestanda och enklare hantering

Här är två citat från sidan ovan

"greater scalability and easier manageability, while extending Internet Information Services (IIS) to provide a standard host for applications that use workflow or communications"

"The company is adding significant functionality to the new version of Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) as part of the .NET Framework 4.0 release, including new messaging and REST capabilities in WCF, new workflow models, seamless integration between WF and WCF to support stateful and conversational services, and a new visual designer"

Johan Lindfors skriver mer om ämnet på sin blogg och där nämner han en tiofaldig prestandaförbättring vilket låter lovande.

Ser verkligen fram mot att landa på PDC, det verkar vara mkt som faller mig i smaken =)

DependenyProperties och FxCop

Har skapat en request på microsoft connect om att FxCop skall tillåta DependencyProperties utan att kräva manuella suppressions.

Läs mer här och rösta gärna på ärendet så det får prioritet.

En DependencyProperty deklararas enligt följande

public static DependencyProperty NameProperty = DependencyProperty.Register("Name", typeof(string), typeof(MyActivity));

Detta bryter naturligtvis mot de designregler som finns men då vi mer eller mindre är tvingade till detta pga den programmeringsmodell som finns i workflow foundation känns det trist att FxCop och StyleCop gnäller.

Enterprise library och workflows

Jag har testat att kombinera Enterprise Library 4.0 med workflows och det är naturligtvis inga större konstigheter till att börja med.

Då jag själv gillar AOP och ville använda policy injection blocket i enterprise library blev jag tvungen att låta mina affärsentiteter ärva från MarshalByRefObject (vet att det går att köra med ett interface också men det hör inte hit) samt skapa/wrappa dem genom PolicyInjection blocket för att få tillbaka den transparent proxy som motsvarar mitt objekt.

[ValidationCallHandler] public void Deposit([RangeValidator(typeof(Decimal), "0.0", RangeBoundaryType.Exclusive, "0.0", RangeBoundaryType.Ignore)] decimal depositAmount) { balance += depositAmount; }

Mitt typiska flöde/aktivitet har ofta en eller flera affärsentiteter kopplade till sig och dessa skall naturligtvis vara serialiseringsbara för att kunna persisteras (genom exempelvis SqlWorkflowPersistenceService )

Nu uppstår problemet.. tyvärr inte med alla objekt utan bara vissa och problemet verkar bero på att serialiseringen smäller vilket i sin tur innebär att flödet är helt trasigt. Hela problemet verkar ha med den transparent proxy som skapas vilket gör att problemets fokus ligger rakt i kärnan på hur funktionen är designad.

Lärdom, använd inte Policy injection för de entiteter som skall serialiseras med ditt workflow.

Resultatet blev att Enterprise Library åkte ut och PostSharp åkte in (utan några problem hittils och inga krav på att ärva från en viss klass eller köra någon wrappning)

.NET 4.0 / OSLO

Som ni säkert sätt börjar det läcka ut nyheter kring .NET 4.0 / OSLO i lagom tid inför PDC.

Ett problem som finns med dagens WF/WCF-lösningar är att den svarande parten (WCF) i princip måste få veta vilken nästa aktivitet i flödet är (vilket motverkar ett av syftena med workflows)

Citat från Matt W's blogg

The first time I did this I spent days working on it saying to myself "surely you don't have to do this... surely you don't have to tell the target service which *activity* you want it to talk to next". But you do. It makes me sad inside.

matt: Our general goal is not to introduce more misery into the world. At this point in time, doing duplex requires the explicit management of the context token. We're working to make it better, so hopefully around PDC time, you will no longer be sad inside

Här är en dragning som jag garanterat skall gå på
http://channel9.msdn.com/pdc2008/TL06

Ska bli kul att se vad mer som finns i .NET 4.0, 3.5 var smaskens men trots allt inte en major version på samma sätt som 3.0 var =)

Long running processes

Att hantera krav på skalbarhet, felhantering, undantagshantering för processer som kan ta lång tid på sig kan vara en utmaning. Ett exempel kan vara en import eller export av data som kan ta allt från minuter till dagar beroende på storlek, nätverk, lagring.

Tänk en flytt av allt innehåll i exempelvis sharepoint där vi har webbar med underwebbar, listor, documentbibliotek och så vidare.

Hur löser vi denna typ av problem på ett effektivt sätt där vi kan korrigera eventuella problem utan att starta om processen från början? Helst med ett automatiskt retry-beteende om exempelvis nätet skulle få hicka.

Svaret är naturligtvis workflow foundation =)

Ofta när vi pratar om workflow foundation så handlar det om processer där människor är inblandade men som tur är så finns det andra användningsområden också.

Med hjälp av persistence kan vi spara ned vårt nuvarande state efter varje operation (ex flytt av ett dokument), vi får även på köpet ett bra verktyg för skalbarhet eftersom vi kan skala ut över flera maskiner utan att skriva någon extra kod för ändamålet (sql-persistence sköter detta åt oss)

Nästa sak på listan är naturligtvis att skapa lite egna aktiviteter, exempelvis en för att hantera en site, en för ett document library och så vidare. I site-aktiviteten lägger vi sedan en repeater som hanterar undersiter, en repeater som hanterar alla listor osv. Dvs vi skapar med väldigt lite kod ett inituitivt flöde med kod som är enkel att underhålla.

Den sista aktiviteten vi bör kika på är naturligtvis en egen retryaktivitet som klarar av att ha en childaktivitet och har ett retry-beteende. Om vi sedan genomgående stoppar våra site, documentlibraryaktiviteter etc. i vår retryaktivitet så slipper vi begåva varje enskild aktivitet med detta. Vi kryddar naturligtvis med loggning och konfigurering.

Workflow foundation är en cool kamrat för oss utvecklare / arkitekter :-)

Match with the Target Type

Råkade ut för en skön grejj i VS 2008's designer för workflow, jag var mitt uppe i lite rejäl refactoring och helt plötsligt kunde jag inte binda en dependency property...

Path resolved to Referenced activity Property 'MyProperty' whose PropertyType 'MyNamespace.MyCustomType' does not match with the Target Type 'MyNamespace.MyCustomType'

Frustrationen växte och jag började fundera över allt möjligt
* Kan det bero på att jag gömt konstruktorn för typen?
* Kan det bero på enterprise library's policy injection?
* Kan det vara min factory som ställer till det?

Vad var då lösningen? Stäng ned visual studion, hämta en kaffe och starta om studion igen. Tydligen är detta ett resultat av någon caching i VS2008 (mer prestanda men tydligen en del buggar kvar..)

Då jag inte tänkte på omstarten direkt tyder det trots allt på att denna typ av problem börjar bli mer sällsynta, måste tänka positivt =)