Newsgroup: it.comp.lang.visual-basic
Titolo: Distribuire FileSystemObject

Se in un progetto uso dei riferimenti al FileSystemObject stando al PDW devo
includere nel pacchetto di installazione questi due files: scrrun.dll e
scrrnit.dll
Cercando in rete non trovo indicato in modo univoco se questi files sono
dipendenti dalla versione di Windows o no, e se quindi posso tranquillamente
distribuire quelli della mia macchina di sviluppo (Win XP) o no. Addiritura
ho trovato che deve essere distribuito ed esegioto un .exe (scr56en.exe se
Win98, Me e NT4.0 o scripten.exe per Win2000 o XP).
Inoltre ho un'altra domanda: se il pacchetto viene installato all'estero, su
una macchina in lingua inglese (o altra lingua), posso fare a meno di
includere scrrnit.dll o rischio di avere degli errori ?
Grazie.

 scrrnit.dll
No, sono file installati con IE4, e non installabili isolatamente.
Il pdw li installa perchè non sa se la macchina target li ha già o 
meno.
Tu hai due strade: o fai due pacchetti, uno per pc senza IE4 e uno per 
pc con IE4 (e in questo secondo pacchetto NON inserisci quei file), 
oppure poni come prerequisito per poter installare il software IE4 o 
superiori, e fai un solo pacchetto.
Qualunque sia la tua scelta, ricordati di usare il createobject per 
istanziare FileSystemObject, e non il New, così ti sleghi dalle diverse 
versioni e dai riferimenti.
Ciao
Alberto
-- 
Fabio Fazio: Se siamo alleati come mai nei nostri bar si vende Coca 
Cola e nei bar americani non si vende l'amaretto di Saronno?

 versioni e dai riferimenti.
Grazie Alberto.
Anch'io pensavo che non fosse necessario installare niente sui SO più
moderni (XP ad esempio) in quanto questi dovrebbero avere di serie il
componente.
Il problema è che alcuni mi hanno detto che su XP hanno il famiferato errore
429, proprio in fase di istanziamento dell'oggetto fso. E' possibile che in
qualche circostanza la dll scrrun.dll non ci sia o non sia registrata ?

ToSka scriveva il 20/01/2009 :

Altamente improbabile.
Però molti antivirus lo bloccano, va gestito.
Alberto
-- 
Heinrich Zille: Ognuno crede che l'altro sia come se stesso, 
dimenticando che al mondo esistono anche delle persone oneste.

 ha scritto nel messaggio
news:mn.a4207d91d...@hotmail.com...


A questo non avevo pensato.. magari lo bloccano in modo silenzioso.
Grazie.

> 429, proprio in fase di istanziamento dell'oggetto fso.
Dimenticavo: questo errore, avviene istanziando con New o con 
CreateObject?
Alberto
-- 
Alessandro Bergonzoni: Il tempo vola e noi no. Strano sarebbe se noi 
volassimo e il tempo no, il cielo sarebbe pieno di uomini con 
l'orologio fermo.

 CreateObject?
Con Create Object: Set Fs = CreateObject("Scripting.FileSystemObject")

 Con Create Object: Set Fs = CreateObject("Scripting.FileSystemObject")
E fs come è dichiarato?
Alberto
-- 
Georges Pompidou: Un uomo di stato è un politico che dona se stesso al 
servizio della nazione. Un politico è un uomo di stato che pone la 
nazione al suo servizio.

> E fs come è dichiarato?
dim fs

 dim fs
Tutto lì?
Mettiamoci anche un 'as Object', dai, che è più bello...
Alberto
-- 
Karl Marx: Uno scrittore è produttivo non nella misura in cui produce 
idee, ma nella misura in cui arricchisce l'editore che pubblica le sue 
opere.

 Mettiamoci anche un 'as Object', dai, che č piů bello...
Avevo trovato degli esempi con Dim fs senza as Object. So che in questo modo
č una variabile Variant, ma in sostanza cosa cambia, a parte essere "piů
bello" ?

 bello" ?
Che Object è genericamente un puntatore ad un oggetto.
Variant può anche diventare un puntatore ad un oggetto generico, ma può 
anche acquisire una sua struttura diversa. Diciamo che è un qualcosa di 
meno deterministico, non puoi mai essere certo di ciò che diventerà al 
momento dell'assegnazione.
Quindi, nel dubbio, se sai già cosa dovrà diventare, meglio 
dimensionare correttamente.
Che poi è anche più bello.
Comunque il pdw è veramente forte, è riuscito a capire che userai un 
variant come FileSystemObject e ti ha inserito i riferimenti a 
ScriptingRuntime. Cavolo, vuol dire che si fa un parsing di tutto il 
codice.
Che in questo specifico caso sarebbe stato meglio che non lo avesse 
fatto, così non ti avrebbe inserito dei riferimenti che è meglio non 
distribuire.
Alberto
-- 
Max Beerbohm: Tutto ciò che è degno di essere fatto è stato fatto 
ripetutamente. Dalle cose mai fatte bisognerebbe tenersi, sospetto, 
molto alla larga.

 distribuire.
Confermo che non lo aveva fatto.
In definitiva sto pensando che forse sarebbe meglio lasciar perdere sta
storia del FileSystemObject a favore delle chiamate dirette in VB, anche per
il fatto che mi dicevi che alcuni antivirus bloccano la dll a priori, dato
che è la stessa che serve a far girare i virus in vbs... mah!
Approfitto quindi della tua cortesia per chiederti una opinione su come
sostituire le chiamate ai metodi del FSO che attualmente uso:
--- FolderExists la sostituirei con (esempio trovato qui sul NG):
Public Function FolderExists(ByVal Path) As Boolean
    FolderExists = Len(Dir$(Path , vbDirectory Or _
                                   vbNormal Or _
                                   vbHidden Or _
                                   vbReadOnly Or vbSystem))
End Function
--- CreateFolder la sostituirei con MkDir
--- DriveExists la sostituirei con l'API GetLogicalDriveStrings (esempio
preso da 
vbnet.mvps.org
:
Public Declare Function GetLogicalDriveStrings Lib "kernel32" _
     Alias "GetLogicalDriveStringsA" _
    (ByVal nBufferLength As Long, _
     ByVal lpBuffer As String) As Long
Private Function DriveExists(drvName As String) As Boolean
   Dim allDrives As String
   allDrives = Space$(64)
   Call GetLogicalDriveStrings(Len(allDrives), allDrives)
   DriveExists = InStr(1, allDrives, drvName, 1) > 0
End Function
--- CopyFile la sostituirei con FileCopy (devo verificare come si comporta
se il file esiste già..)
Che ne pensi ?

Nel suo scritto precedente, ToSka ha sostenuto :

Quando devo fare qualcosa di piccolo e di distribuzione unattended (ad 
esempio roba che si scarica da web e l'utente si deve installare senza 
romperci le palle), non uso FileSystemObject, e faccio come ipotizzi tu 
(grossomodo, non sto a verificare il codice).
Però in alcuni casi ho avuto dei problemi, con FileCopy, che non si 
presentavano con Fs.CopyFile (ad esempio la copia di un file da una 
cartella di rete ad un'altra, teneva loccato il file di origine durante 
la copia, col risultato che un altro applicativo di terze parti si 
inchiodava).
Alberto
-- 
Konrad Adenauer: All'intelligenza Dio ha posto limiti, alla stupidità 
no.

 inchiodava).
Ok, ma se e non so come si comportano i vari antivirus continuare ad usare
l'FSO mi sembra una scelta masochistica..
Vabbè, vedremo.
Grazie di tutto!