Hej. Du har inte kompilerat om dina andra assemblys under tiden? Länken till en assembly är väl till en specifik version om jag inte har missat något? I sådana fall måste du ha samma version på dina assemblys som du hade på dem lokalt när du kompilerad webapplikationen. Jo, det kan vara så - i en del fall. Staffan, Tack för svaret Andreas staffan, Hm... Jag inbillar mig att så länge man inte har strongname så och undviker gac så är det lugnt att kompilera om hur mycket man vill bara man inte ändrar det som syns publikt eller kör ngen på de... Har för mig att jag gjort så några gången nämligenDeployment-problem
Jag arbetar med en ASP.NET applikation som ligger på ett webhotell (fsdata).
Den består bl a av ett antal assemblys:
En som innehåller ADO.NET för MySQL (köpe-komponent)
Samt egna assemblys som är
ett databaslager
ett buiziness lager
samt diverse andra för utilities etc. Några av de sista är signade med en strong key.
Och så förståss hela webbapplikations assembly som blivit kompilerad i VS.NET.
Så till problemet:
När jag har gjort en ändring i t ex bara webbapplikationen så tänker jag att då borde det räcka med att enbart FTP:a upp den enda assemblyn till webbhotellet.
MEN då får jag ett fel av typen ”System.IO.FileLoadException” – förmodligen då det skall laddas in en assembly.
Enda lösningen jag kommit på är att ladda upp samtliga assemblys på nytt.
Men hallå, var det så det var tänkt med xcopy deplyoment eller?
Någon som har ett tips inom detta?
Kan det hjälpa om jag struntar i att signa mina egna assemblys med strong key? Kan låta sig göra med blir lite knepigt av olika orsaker som inte har betydelse här.
Är det kanske ngn inställning på webbservern? OS = NT 5.0.2195.0.
Tacksam för tipsSv: Deployment-problem
/JohanSv:Deployment-problem
De kan dessutom bara vara omkompilerade med precis samma källkod och samma version i Assemblyinfo.cs. Men jag får samma fel ändå
Men det är oxå så att de inte har blivit ändrade, och ändå uppstår samma fel.
Jag har märkt det hjälper att jag "stänger" sajten & ser till att ingen ny besökare kommer in medan jag uppdaterar. Annrs kan jag tvingas att kopiera upp DLL-erna ett par ggr inna det går som det ska.Sv: Deployment-problem
De referenser som ditt projekt har elimineras inte när du kompilerar, dvs. de byggs inte in som resurser i din dll fil. Det betyder att du måste kopiera över samtliga dll:er som finns i din bin-katalog (VS.NET samlat ihop dem till dig). Dessa kan du sedan XCOPY distribuera - för vad det innebär är att du inte behöver registrera komponenter etc vid distribution.. med COM komponenter var man tvungen att registrera dem.. dock så om du har COM dependencies (COM Wrappers), använder dig av 3e parts .NET produkter som registrerar sig i GAC:n mm så är det en annan femma..Sv:Deployment-problem
Jag trodde att om man t ex bara ändrade en av sina assemblys, så kunde man bara ladda upp den enbart, om bara versioner etc var samma.
Men OK jag får väl lida mig igenom att kopiera allt på ett bräde.
Inte för at det är ngt problem att kopiera hela bin-katalogen i o för sig men jag får allt som oftast problem av just typen System.IO.FileLoadException när jag gör det. O kommer inte runt detta annat än gm att kopiera upp allt på nytt. Utan omkompilering. Lite mystiskt är det.
/StaffanSv: Deployment-problem
Om du gör en ändring i projekt A som projekt B har en referens till.. sen kompilerar du..då måste du ladda upp både den dll:n som projekt A kompileras till, samt den som projekt B kompileras i. Om du har projekt A och projekt B, utan några som helst referenser mellan dem, och gör en ändring i någon av dem, så räcker det att du laddar upp dll:n för det projektet du ändrat.
Tänk på att som default så räknas revision för dina dll:er automsikt upp varje gång du kompilerar. För att ställa detta får du få in i din AssemblyInfo fil och ändra Version taggen till att inte använad en asterix.Sv:Deployment-problem