Exemplo de aplicação gethrforexception

Eu tenho um código IO que lê um fluxo dentro de um try..catch. Ele captura IOException e chama System. Runtime. InteropServices. Marshal. GetHRForException () dentro da captura, em uma tentativa de executar ações diferentes com base no HResult. Algo como isto: Mas executando este código dentro do ASP. NET com trustmedium, recebo esta exceção: Algumas perguntas: Acho que a exceção está ocorrendo porque GetHRForException chama em código não gerenciado, o que não é permitido em confiança média. Correct Esta exceção está sendo lançada, não no momento da execução de GetHRForException, mas no momento em que o método está sendo JITed - Correct (O stacktrace mostra meu método, mas tenho certeza de que uma exceção de IO não ocorreu) Em caso afirmativo, Existe uma maneira para eu variar o comportamento em um ambiente de confiança parcial, para que eu não chame o GetHRForException (código não gerenciado) onde não é permitido Em outras palavras, como posso permitir que o JIT seja bem-sucedida em tempo de compilação, enquanto também avaliando em tempo de execução se o código deve chamar GetHRForException () Algo como isto: Eu acho que existe um mecanismo de tempo de execução para testar se as permissões estão disponíveis, mas não conseguiram encontrá-lo. EDIT É este artigo de blog a resposta ShawnFa da Microsoft diz que você não pode fazer uma tentativa. catch (SecurityException) em torno de um método protegido por um LinkDemand. Se MethodA () chama MethodB () e MethodB () é marcado com LinkDemand para confiança total, o LinkDemand é verificado com MethodA é Jited. Portanto, para evitar o SecurityException, eu preciso extrair o Marshal. GetHRForException em um método separado. Isso é correto? Aplicado ao meu código, MethodA () pode ser o código que chama Read e, em seguida, no catch tenta chamar GetHRForException (). GetHRForException é MethodB (). O LinkDemand é avaliado quando o MethodA () é JITd. (Esse LinkDemand falha no meu cenário ASP. NET de confiança média). Se eu mover o GetHRForException em um novo método, MethodC () e condicionalmente chamar MethodC () somente após um imperativo permission. Demand () tiver sucesso, teoricamente eu deveria ser capaz de evitar o SecurityException no tempo JIT, porque MethodC () será JITd somente após a permissão. Data () é bem-sucedida. perguntou 12 de julho 09 at 14:20 O método necessário é SecurityPermission. IsUnrestricted (). Retorna um verdadeiro ou falso, indicando se a permissão é permitida ou não. Ele não exige permissão, assim como SecurityPermission. Demand (). Eu uso IsUnresticted com SecurityPermissionFlag. UnmanagedCode para ver se o assembly tem permissão para chamar código não gerenciado e, em seguida, chamar o código não gerenciado somente se permitido. Há um toque adicional. O compilador JIT, ao compilar um método, procura por CodeAccessPermission LinkDemands em qualquer método chamado meu método a ser compilado. Marshal. GetHRForException () é marcado com um LinkDemand. Portanto, meu método que chama Marshal. GetHRForException () lançará uma SecurityException não conectável no momento da compilação JIT, quando executada em um ambiente restrito, como o ASP. NET com confiança média. Portanto, nunca devemos JIT o método que chama Marshal. GetHRForException () nesse caso, o que significa que eu preciso separar Marshal. GetHRForException () em um método separado no meu código que é chamado (e portanto, JITted) somente quando UnmanagedCode é irrestrito. Heres algum código de exemplo: respondeu Jul 20 09 at 17:56 Sim - confiança média não permitirá chamadas em código não gerenciado. O único nível de confiança que permite isso é a confiança total. Depende. As demandas do CAS podem ocorrer em tempo de execução, mas o ambiente de hospedagem também pode viajar e procurar coisas que não podem fazer. Você pode testar para ver se pode fazer uma chamada para código não gerenciado usando uma demanda de CAS com uma instância de SecurityPermission. O código para fazer uma demanda de CAS se parece com isso respondido 12 de julho de 09 14:32 OK, esta é uma ótima informação. Isso cobre a parte b do Q3. Mas que tal uma parte como faço para obter a compilação JIT para ter sucesso Posso marcar meu método com um atributo de segurança ou. Lembre-se, minha teoria é que o erro SecurityPermission não está acontecendo em tempo de execução, está acontecendo durante o JIT - e eu acho que você confirmou que isso é possível. Então a questão é, como eu escrevo o código para permitir que o JIT compile. ndash Cheeso Jul 12 09 at 15:50 Deveria estar acontecendo em tempo de execução, caso contrário a montagem não seria carregada - e para isso acontecer a montagem precisa ser marcada como exigindo a permissão. Mesmo assim, é indiscutivelmente uma verificação de tempo de execução, como acontecerá na carga de montagem, que poderia estar em tempo de execução. ndash blowdart Jul 12 09 at 16:24 Tipo diferente de verificação, demandas de link são atributos em um método, e são de fato verificados no tempo JIT. Ele é muito usado pelo próprio framework e é raro vê-lo fora da fonte CLR. O que eu demonstro é uma exigência imperativa, não declarativa como um blowdart de segurança SecurityPermission (SecurityAction. LinkDemand, Unrestricted true) Jul 12 09 at 18: 55Quiz: Gotcha with Exceptions e HRESULTs Bem, tanto ENOINTERFACE quanto EPOINTER HRESULT são mapeados para um InvalidCast exceção por ThrowExceptionForHR. Uma vez que uma exceção InvalidCast é lançada, o mesmo HRESULT será retornado de GetHRForException (they8217re a mesma exceção nesse ponto). O motivo pelo qual 0x8004002 é exibido nas duas vezes é que o objeto de erro não está sendo redefinido entre os dois blocos try / catch. antes do primeiro try / catch o objeto de erro associado ao thread lógico está vazio, após o try / catch o valor HRESULT do objeto object8217s é definido como 0x8004002. Agora, o segundo bloco try / catch é executado e o GetErrorInfo () é executado para definir o valor COMException. HRESULT como o valor do objeto de erro (que já está definido como 0x8004002), portanto, o valor COMException. HRESULT é definido como 0x8004002. Deixe-me ver se consigo criar um exemplo8230 Bem, consegui demonstrar porque isso está acontecendo (veja o código abaixo). Eu inseri uma chamada para criar uma nova instância do Excel. ApplicationClass no servidor COM do Excel. Qualquer chamada entre apartamentos que utilize um proxy-stub ou qualquer chamada COM em um apartamento que use o loop de mensagem COM (STA) limpará o objeto de informação de erro. Assim, a chamada para o objeto COM do Excel entre as exceções capturadas apagará o objeto info de erro: class Classe1 const int ENOINTERFACE desmarcada ((int) 0x80004002) const int EPOINTER desmarcada ((int) 0x80004003) private Excel. Application ExcelApplication null Muito bom observações, todo mundo Ordinariamente, ENOINTERFACE é mapeado para InvalidCastException e EPOINTER é mapeado para NullReferenceException. Mas, como Fernando destacou, ambas as exceções lançadas neste exemplo são InvalidCastException. Isso explica por que GetHRForException retorna ENOINTERFACE em ambos os casos, mas por que obtemos uma InvalidCastException duas vezes O método ThrowExceptionForHR lança uma exceção cujo tipo corresponde ao valor HRESULT de entrada (ou uma COMException contendo HRESULT se a entrada HRESULT é isn8217t na tabela de mapeamento CLR8217s) . Mas ele faz mais do que isso: chama a API Win32 GetErrorInfo para tentar recuperar um objeto de erro disponível no thread atual. Ele usa essas informações para fornecer à exceção uma mensagem de erro personalizada, origem e assim por diante. ThrowExceptionForHR também tem uma sobrecarga com um segundo parâmetro System. IntPtr que representa um ponteiro para uma interface IErrorInfo, para que você possa passar essas informações diretamente. Passar IntPtr. Zero significa que você deseja que a API atue como a sobrecarga de parâmetro único (e chame GetErrorInfo), e passar -1 desabilita a recuperação extra das informações. O GetHRForException método recupera o valor HRESULT para qualquer exceção gerenciada. Esse é o valor da propriedade quotHResultquot protegida da exception8217s, que você normalmente pode acessar diretamente. Mas esse método tem um efeito colateral: ele chama a API Win32 SetErrorInfo, passando o CCW para exceção (que implementa IErrorInfo apropriadamente). Ele faz isso para facilitar a imitação do comportamento do marshaler8217s ao expor manualmente uma exceção como um HRESULT e IErrorInfo para COM. Neste exemplo, a primeira chamada para GetHRForException faz com que o CLR chame SetErrorInfo com o objeto InvalidCastException empacotado. Devido a isso, a segunda chamada para ThrowExceptionForHR pega essas informações quando ele chama GetErrorInfo, como Phil apontou. A razão pela qual isso afeta o tipo da exceção emitida 8211, apesar do fato de IErrorInfo não possuir um mecanismo para recuperar um HRESULT 8211 é que o CLR pode detectar quando o objeto de erro recuperado de SetErrorInfo se originou como uma exceção gerenciada e apenas reutilizar essa exceção original. Tudo isso significa que não importa o que HRESULT é passado para o método ThrowExceptionForHR a segunda vez (contanto que seja uma falha HRESULT), a exceção gerada é sempre um InvalidCastException. Para obter o comportamento normalmente esperado, você pode usar a sobrecarga de ThrowExceptionForHR que ignora IErrorInfo: using System using System. Runtime. InteropServices public class Quiz const int ENOINTERFACE desmarcada ((int) 0x80004002) const int EPOINTER desmarcada ((int) 0x80004003) public static void Main () tente Marshal. ThrowExceptionForHR (ENOINTERFACE) catch (Exceção ex) Console. WriteLine (quot0x quot, Marshal. GetHRForException (ex)) Este novo código imprime: Phil perguntou por que Marshal. GetLastWin32Error sempre retornava 0 não importava onde ele inserido. That8217s porque GetLastError / SetLastError é um mecanismo separado de GetErrorInfo / SetErrorInfo. O primeiro mecanismo nunca está envolvido aqui. E, sim, o código gerenciado nunca deve chamar GetLastError diretamente. Veja: blogs. gotdotnet / anathan / PermaLink. aspx / 6d021f27-72c8-4420-b6ad-1c5f0690bde8 Lamento que minha guestion não esteja relacionada ao assunto. Gostaria de saber que como posso reunir informações de uma página, por exemplo, obter o código html de uma página especial no meu ASP ou apllication ASP. NET e usá-lo no meu aplicativo. para o exemplo recebo o código html de quotanysite quot e então use este código em minha página programando. I8217viu ver pessoas suficientes perguntando sobre isso, então eu pensei que deveria falar sobre isso no meu blog. Eles vêem o estranho TypeLoadException de primeira chance acontecendo em seu aplicativo, mas ele não parece nunca causar nenhum problema (o aplicativo não trava) e tudo ainda parece funcionar 8216fine8217. Isso parece acontecer principalmente se você tiver um. NET interoperabilidade e WinRT nos dias de hoje, async / wait ainda é o único tópico que me deixa confuso de vez em quando Tempo. Ele é um ótimo conceito logicamente, mas difícil de entender quando você começa a pensar em como o fluxo real do código se vai (e todo o inferno se solta quando você começa a depurar o 8230 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 Vamos dizer que você tem uma função de exportação em sua DLL nativa: void WINAPI MyFunction (comptrtltIMyInterfacegt ptr) E o DllImport seria algo como isto: DllImport (quotmydll. dllquot) void MyFunction (IMyInterface ptr) Tudo parece ser perfeitamente válido, exceto I8217m vendo muitas pessoas relatando que estão vendo estranhos problemas de P / invocação quando eles moveram seu código para o VS 2012. Normalmente, eles têm P /. invoca assim: DllImport (quotWin32Project2.dllquot, PreserveSig true, CharSet CharSet. Unicode) estático extern int MyPInvoke (out string ret) Se você anexar um depurador nativo (ou enab depuração nativa), com os símbolos corretos (public symbol8230 24 de janeiro de 2013 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 Primeiro, Let8217s comece observando um pequeno trecho de código: if (Marshal. GetHRForException (myException) ESOMECOMERROR) DoSomething () Isso parece perfeitamente bem, certo Não é verdade. Acontece que essa API é mal nomeada e, na verdade, faz mais do que apenas recuperar o HR do objeto de exceção. Usando esta API incorretamente poderia lhe dar alguns problemas estranhos, 8230 18 de janeiro de 2013 x2605 x2605 x2605 x2605 x2605 x2605 x2605 Eu aprendi esse truque de depuração de um colega alguns dias atrás Não posso esperar para compartilhá-lo. Conceitualmente, é realmente uma idéia simples, mas é muito útil. Vamos dizer que você está depurando um acidente. Você sabe que o bug provavelmente está em funcionamento xxxxx x2605 x2605 x2605 x2605 x2605 x2605 Recentemente, obtive o Samsung Focus, mas ele não foi reconhecido pelo Zune Software que diz Não há dispositivo conectado, mesmo que meu telefone tenha ligado um som quando se conecta ao meu computador e o software zune apareceu. Passe meia hora procurando por soluções e me deparo com este artigo: microsoft / windowsphone / pt-nos / howto / wp7 / basics / the-zune-software-doesnt-reconhece-meu-phone. aspx Um dos8230 21 de dezembro de 2010 1 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 O que é 0x8013XXXX Ocasionalmente, você pode executar no HRESULTs misterioso retornado do. NET que começa com 0x8013, por exemplo, 0x80131522. Infelizmente, a pesquisa de erro fornecida com o Visual Studio não funciona nesses HRESULTs estranhos. O que são eles? Na verdade, eles são definidos pelo. NET / CLR nos arquivos de cabeçalho. Todas essas falhas / êxito8230 17 de dezembro de 2010 0 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605 x2605