Jeg arbejdede på en funktion i sidste uge, som vil tilføje nogle hændelsesmodtagere til en bestemt liste forekomst. (Jeg blogges lidt om at listen modtager her).

Ved hjælp af kommandolinjen, Jeg kunne installere funktionen med ingen fejl (Men se nedenfor for de skjulte fejl). Da jeg prøvede at installere funktionen på webstedet, MOSS klagede over en "FileNotFoundException" fejl. Dette blogindlæg beskriver, hvordan jeg løst det.

Indeværende er den fejl, at MOSS viste mig i webbrowseren:

Funktionen ' b2cb42e3-4f0a-4380-Hanss-1ef9cd526f20’ kunne ikke installeres, fordi indlæsning af begivenhed receiver forsamling "xyzzyFeatureReceiver_0" mislykkedes: System.IO.FileNotFoundException: Kunne ikke indlæse filen eller assemblyen ' xyzzyFeatureReceiver_0’ eller en af dens afhængigheder. Systemet kan ikke finde den angivne fil. Filnavn: ' xyzzyFeatureReceiver_0’ på System.Reflection.Assembly.nLoad(AssemblyName filnavn, Streng codeBase, Beviser assemblySecurity, Assemblyen locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) på System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Beviser assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) på System.Reflection.Assembly.InternalLoad(Strengen assemblyString, Beviser assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) på System.Reflection.Assembly.Load(Strengen assemblyString) på Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject() WRN: Forsamling bindende logføring er slået fra. Du aktiverer forsamling binder fiasko logføring, indstille registreringsdatabaseværdien [HKLMSoftwareMicrosoftFusion!EnableLog] (DWORD) til 1. Bemærk: Der er nogle ydeevne sanktion tilknyttet forsamling binder fiasko logføring. Slå denne funktion fra, ophæve den indskrive værdi [HKLMSoftwareMicrosoftFusion!EnableLog]. Fejlfinding af problemer med Windows SharePoint Services.

Jeg ved, hvordan man bevidst forårsage denne fejl: ikke installere assemblyen i GAC. Men, Det var i GAC. Jeg installere normalt forsamlinger i GAC ved at trække dem til c:\windowsassembly mappe ved hjælp af windows Stifinder. Jeg har aldrig følt 100% komfortable gør, fordi jeg altid troet, at gacutil eksisteret en grund … så jeg prøvede at. Det gjorde ingen forskel.

Jeg søgte Internets og fandt dette indlæg: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2243677&SiteID=1

Plakaten tilfældigvis skal bruge den samme rod bit kode (fra bogens inde WSS fra denne liste) så det var et lovende tegn. Dog, forslaget om udsmykning forsamling med et [forsamling: ] direktiv giver ikke mening for mig. Jeg prøvede det alligevel og jeg havde ret. Det gjorde ingen forskel.

Så jeg bemærket, at min klassedefinitionen ikke var offentlige. Jeg gjorde det offentlige og det gjorde ingen forskel.

Næste, Jeg gik til besværet med at aktivere "forsamling binder fejl log" (på grundlag af nyttige og præcise instruktioner) og dette er, hvor ting begyndte at blive interessant. Denne log viser mig, at runtime søger overalt på den pågældende server til min samling. Det synes selv at være at søge efter det i mit medicinskabet. Men … det vil ikke søge efter det i GAC.

Jeg sætter på min vinterjakke og gå søger Internets igen og finde, at nogen har haft dette problem også. Den langvarige diskussion i denne udstationering peters off i noget og jeg kan ikke finde en løsning.

Jeg flytter min samling til et af de steder log hævder det søger og jeg komme lidt videre. Jeg er belønnet med en ny fejl i browseren, når jeg forsøger at aktivere funktionen:

Det mislykkedes at oprette funktion modtager objektet fra forsamlingen "xyzzyFeatureReceiver_0", Skriv "Conchango.xyzzyFeatureReceiver" for funktionen b2cb42e3-4f0a-4380-aaba-1ef9cd526f20: System.ArgumentNullException: Værdi må ikke være null. Parameternavnet: type på System.Activator.CreateInstance(Type type, Boolean nonPublic) på System.Activator.CreateInstance(Type type) på Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject() Fejlfinding af problemer med Windows SharePoint Services.

Tid til en sidste tur til Internets!

Denne gang jeg finde ud af, forudsigeligt nok, at MOSS spørgsmål denne fejl, fordi assemblyen ikke er i GAC.

Jeg ønsker at få noget positivt ud af det og forsøge at være lidt stolt, at jeg har lavet den Diffus MSIL forsamlinger, men det er ikke i orden. Jeg er bare plain irriteret. Jeg befinder mig mumler "hønen eller ægget" under min ånde.

Jeg endelig beslutter at punt. Jeg oprette et helt nyt projekt og copy/paste koden fra incredible-cloaked-from-the-GAC-assembly ikke-arbejdende projektet over dette nye projekt. (Jeg søger en bygge flag kaldes noget som "Skjul fra assemblyen bindende, hvis installeret i GAC" men kan ikke finde en).

Jeg installere funktionen og aktivere den og … det virker! Så, efter alle, Jeg måtte dybest set ' genstarte’ mit projekt. Dette er en anden grund til hvorfor jeg hader computere.

Jeg har lære noget nyttigt fra dette. Jeg havde installation af funktioner ved hjælp af kommandolinjen stsadm hele dagen lang og brugt den "-kraft" indstilling ud af vane. For anden grund, Jeg ikke bruger - kraft valgmulighed da jeg installerede det nye projekt. Denne gang, Jeg gjorde faktisk, virkelig Glem at kopiere dette nye projekt assembly til GAC. Som et resultat, Jeg fik denne "FielNotFoundException" fejl. Denne gang, Jeg fik det fra stsadm, ikke, når jeg prøvede at aktivere funktionen via en webbrowser. Så, -kraft faktisk spiller to roller. Gør det muligt at re-installere en eksisterende funktion. Det giver også mulighed for at installere en buggy funktion, der ikke kan arbejde på kørselstidspunktet ved at undertrykke fejlen. Det siger nok så meget i hjælp til et eller andet sted, men jeg lagt mærke aldrig til det.

</slutningen>

OPDATERING: Dette virker, men der er væsentlige begrænsninger, der er beskrevet i kommentarerne. Dette kan stadig være nyttigt i nogle omstaendighederne.

OPDATERING 2: I min aktuelle projekt, brugerne overføre altid dokumenter. Som et resultat, Jeg løbe ikke ind i et problem, hvor MS Word kører og mener, at filen blev omdøbt på det. Jeg løbe ind i et problem, "filen blev ændret af en anden" og løst dette via en simpel semaphore type flag. Brugernes savn hen til ændre en meta datafelt fra standardværdien til noget andet. Af itemupdated() modtageren ser til en gyldig værdi der før du faktisk udfører omdøbe og siden da, Jeg har ikke haft nogen problemer. Din kilometertal kan variere.

Jeg har en klient kravet om at ændre navnet på filer uploades til et bestemt dokumentbibliotek i overensstemmelse med en bestemt navngivningskonvention. API indeholder ikke et "Omdøb()" metode. I stedet, Vi bruger "MoveTo(…)". Her er en minimal smule kode til at opnå dette:

 offentlige tilsidesætte void ItemAdded(SPItemEventProperties egenskaber)
        {
            SPFile f = egenskaber.ListItem.File;

            f.MoveTo(egenskaber.ListItem.ParentList.RootFolder.Url + "/xyzzy.doc");
            f.Update();

        }

Den kun tricky bit er "egenskaber. ListItem.ParentList.RootFolder.Url". MoveTo() metoden kræver en URL. Der mosede op streng point mig til rodmappen på mit aktuelle dokumentbibliotek. Dette tillader mig at undgå hårde kodning i min begivenhed modtager.

Dette er en mere nyttige version, der gør de samme ting, men tildeler navnet på filen til "Titel":

 offentlige tilsidesætte void ItemAdded(SPItemEventProperties egenskaber)
        {
            DisableEventFiring();

            // Tildele titlen på denne post til navnet på selve filen.
 // NOTE: Denne opgave skal finde sted, før vi ændrer selve filen.
 // Kræver opdatering() på SPFile synes at afkræfte egenskaber i
 // nogle følelse.  Opdateringer til "titel" mislykkedes indtil der ændrer (og opdatering() opkald)
 // blev flyttet foran ændringen til filnavnet.
            egenskaber.ListItem["Titel"] = egenskaber.ListItem.File.Name;

            egenskaber.ListItem.Update();

            SPFile f = egenskaber.ListItem.File;

            // Få en udvidelse af fil.  Vi har brug for det senere.
 streng spfileExt = nye FileInfo(f.Name).Udvidelse;

            // Omdøb filen til listeelementets ID og bruge fil forlængelsen at holde
 // del af det intakt.
            f.MoveTo(egenskaber.ListItem.ParentList.RootFolder.Url +
                "/" + egenskaber.ListItem["ID"] + spfileExt);

            // Begå farten.
            f.Update();

            EnableEventFiring();
        }