O lançamento de um aplicativo auxiliar mime registrado

Question

Eu costumava ser capaz de lançar um aplicativo auxiliar instalado localmente por registrar um determinado tipo mime no registro do Windows. Isto permitiu-me para permitir que os usuários possam clicar uma vez em um link para a instalação atual do nosso aplicativo de navegação interna. Esta multa trabalhou no Internet Explorer 5 (a maior parte do tempo) e Firefox, mas agora não funciona no Internet Explorer 7.

O nome do arquivo passado para o meu shell / / comando aberto não é o caminho físico completo para o pacote baixado instalar. O caminho parâmetro estou entregue pelo IE é

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
  EIPortal_DEV_2_0_5_4[1].expd"

Esta, infelizmente, não é resolvido para o arquivo físico ao chamar FileExists() ou ao tentar criar um objeto TFileStream.

O caminho físico está faltando o caching sub-diretório Internet Explorer oculta para Temporary Internet Files of "Content.IE5\ALBKHO3Q" cujo caminho absoluto seria expresso como

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\ 
  Content.IE5\ALBKHO3Q\EIPortal_DEV_2_0_5_4[1].expd"

Sim, os sub-diretórios são gerados aleatoriamente pelo IE e isso não deve ser uma preocupação desde que o IE passa o caminho completo para o meu aplicativo auxiliar, que infelizmente não está fazendo.

A instalação do aplicativo mime helper não é uma preocupação. Ele é instalado / atualizado por um login script global para todos os mais de 10.000 usuários em todo o mundo. O auxiliar mime só é invocado quando o usuário clica em uma página web interna com um link para uma instalação do nosso aplicativo de navegação Desktop. Essa instalação é servido de volta com um tipo de mime de "application/x-expeditors". O registro dos olhares ".expd" / "application/x-expeditors" mime-type como este.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.expd] 
@="ExpeditorsInstaller"
"Content Type"="application/x-expeditors"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller]
"EditFlags"=hex:00,00,01,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open]
@=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open\command]
@="\"C:\\projects\\desktop2\\WebInstaller\\WebInstaller.exe\" \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/x-expeditors]
"Extension"=".expd"

Eu tinha considerado enumerar todas as entradas de cache do IE de um usuário, mas eu ficaria preocupado com quanto tempo pode demorar para examinar todos eles ou que eu possa acabar encontrando uma entrada de cache mais velho antes da entrada atual que estou procurando. No entanto, a enquadradas filename sufixo "[n]" pode ser a chave única.

Eu tentei método wininet GetUrlCacheEntryInfo mas que requer o URL, não o caminho virtual entregue pelo IE.

A minha esperança é que existe uma função Shell que, dado um caminho virtual irá devolver o caminho físico.

Answer 1

Alguns de acompanhamento para fechar esta pergunta.

Acabou a verdadeira questão era como eu estava criando o identificador de arquivo usando TFileStream. Mudei para abrir com fmOpenRead ou fmShareDenyWrite que resolveu o que acabou por ser um problema de bloqueio de arquivos.

srcFile := TFileStream.Create(physicalFilename, fmOpenRead or fmShareDenyWrite);

Answer 2

Eu acredito que os sub-diretórios criados pelo IE são gerados aleatoriamente, para que você não será capaz garantia de que ele será chamado o mesmo cada vez, eo problema que eu vejo com o método de registro é que ele só funciona quando o arquivo ainda está no cache ... esvaziar o cache iria limpar o arquivo exigindo ainda uma outra instalação.

Não seria melhor para instalar esse auxiliar em dados de aplicativos?

Answer 3

Eu não tenho certeza sobre isso, mas talvez isso pode levá-lo na direção certa: tentar usar funções de cache URL do wininet DLL: FindFirstUrlCacheEntry , FindNextUrlCacheEntry , FindCloseUrlCache para enumeração e quando você localizar uma entrada cujo nome de arquivo local corresponde ao caminho dado talvez você pode usar RetrieveUrlCacheEntryFile para recuperar o arquivo.

Answer 4

Eu estou usando um sistema semelhante com o navegador X-Appl para exibir aplicações web WAML e ele funciona perfeitamente. Talvez você deve ter um olhar para como eles conseguiram fazê-lo.

Answer 5

Parece que iexplore está passando o "nome" shell namespace do arquivo em vez do nome do sistema de arquivos.

Eu não acho que há uma maneira documentada para ser passado um ID de item de shell na linha de comando - explorador faz isso para si mesmo, mas há empacotamento considerações como IDs de item shell são (ponteiros) as estruturas de dados binários que só são válidas em um único processo.

O que eu poderia tentar fazer é: 1. Chamada SHGetDesktopFolder que irá retornar o objeto IShellFolder raiz do namespace shell. 2. Ligue para o IShellFolder :: ParseDisplayName para transformar o nome que é dado de volta para uma lista ID de item de shell. 3. Experimente o IShellFolder :: GetDisplayNameOf com a bandeira SHGDN_FORPARSING - que, francamente, parece w'eve acabado em um círculo completo e estão de volta onde começamos. Porque eu acho que seus isso é esta API em última instância responsável por devolver o "errado" filesystem relativa.