Idiotiskt att denna dll inte kommer med i FrameWork 1.1 plus .Net ServicePack1.

Tog mitt program från min gamla dator till den nya Windows XP jag hade och fick detta fåniga meddelande/symptom:
Application popup: WindowsApplication15.exe - Common Language Runtime Debugging Services : Application has generated an exception that could not be handled.

Process id=0xb18 (2840), Thread id=0xb4c (2892).

Click OK to terminate the application.
Click CANCEL to debug the application.


Jag fick återskapa applikationen tills jag hitta den lilla rad kod som gjorde att applikationen inte fungerade.
Jag hade i baktankarna att det var något som saknades så jag gjorde en jämförelse mellan gamla datorn och nya med windows xp.
Hela GAC katalogen saknades men jag läste att den endast var nödvändig om man ville dela komponenter mellan olika program. Däremot så fattades mshtml.dll och jag löste det genom att kopiera den filen från gamla datorn till nya.

Nu undrar jag om jag gärna vill skicka ut ett program och det då saknas dllr hur tar jag reda på det innan så att jag kan vara säker på att programmet funkar?

Går det att på något sätt att ställa in när man kompilerar att filerna ska inkluderas i programmet?


MVH Andla

Du kan inte kompilera in delade dller utan det måste du göra ett installationspaket för att lösa.

Kan man inte kompilera in dll:n som en resurs och sedan programmatiskt skriva in den i assembly mappen om den saknas?

Brukar det som regel vara att objektreferenser som man manuellt lägger in också måste manuellt kopieras i installationen?

Det enda som händer när du lägger till något som en referens är att du möjliggör användandet av det objekt som referensen pekar på. Inget annat. Det är sedan helt och hållet ditt bekymmer att se till att det som referensen pekar på finns tillgängligt på målsystemet, har alltid varit så, kommer antagligen alltid vara så...

Ang. att lägga in en dll som resurs:

Visst, det är möjligt. När du säger Assembly antar jag att du syftar på GAC? Hur som haver, tänk på att oavsett om du lägger dll:en i GAC eller i samma mapp som programmet så måste den som kör, inte installerar, programmet ha admin-rättigheter. Smartare vore att se till att ha ett installationsprogram, installationsprogrammet kräver då admin-rättigheter, men att köra programmet kräver inte längre admin-rättigheter

Du kan inte ha den som en resurs och programmatiskt packa upp den, av den enkla anledningen att applikationen inte kommer att starta om den inte hittar den.

Det är som oskar säger, en referens ber bara om att få arbeta med den dlln, om den inte finns är inte applikationens bekymmer utan det är ditt som utvecklare. Det är därför alla seriösa applikationer kommer med installationspaket, för att få med allt som behövs.

>Du kan inte ha den som en resurs och programmatiskt packa upp den, av den enkla anledningen att >applikationen inte kommer att starta om den inte hittar den.
Du har så rätt och jag är helt sömnig idag :-) ( var piggare igår)

Hmm kan man använda referenser dynamiskt (endast när den behövs). Jag menar att när programmet är laddat då först kollar den om den kan använda mshtml.dll?

Vore rätt flexibelt.

> Hmm kan man använda referenser dynamiskt (endast när den behövs). Jag menar att när programmet är laddat då först kollar den om den kan använda mshtml.dll?

Om du splittar upp ditt program lite grann så borde gå att ordna med reflection, dvs. att dynamiskt ladda assemblies, anropa metoder utefter namn i runtime och liknande. Men det är inte särskilt smidigt.

En variant är att du har ett Dummy-program, den är inte beroende av en massa saker. Det programmet har i sin tur ditt riktiga program och dll-erna som behövs som resurser. Sedan kan den packa upp filerna vid runtime på ett temporärt ställe och sedan exekvera. Egentligen är det ingen snygg lösning, snyggare är att du ha filerna som resurser, sedan stoppar du in dem i en byte-array vid runtime och laddar in dem med någon metod som jag har för mig finns på AppDomain-klassen. Det sista du laddar in är själva programmet som då exekveras. Det är den klart snyggaste lösningen då den inte gör programmet beroende av rättigheter att spara saker på disken ;) Dessutom blir det bara ett program som exekveras och det är just ditt dummy-program (som då internt exekverar ditt riktiga program, men det är inte någon som kommer se någon skillnad ändå...)

du menar att skapa ett eget installationsförfarande skiljt från MSI? Tycker jag låter lagom onödigt

Nope, ingen installation. Allt den behöver har den som resources, sedan laddar den in dll-erna istället för att ta omvägen över disk.

Alltså nu är jag helt puckad. Det var ju bara att droppa in mshtml.dll:n i mappen som programmet kör så funkar det. Behövs ingen specialare. *Super nice*.

Nu skulle man bara behöva ett verktyg som tar reda på vilka dllr som saknas.
Jag har testat windbg och dependency walker och ingen av dom talade om att mshtml.dll saknades.