• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

Grulip

[ajuda] aplicação e dll

24 mensagens neste tópico

Tenho uma aplicação que utiliza uma dll é possivél eu incorporar essa dll na minha aplicação para ficar tudo num só executavél???

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

References > Add Reference ... depois fazes o browse e seleccionas a DLL que queres.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boas,

O pretendido é que fique apenas o executável, mas penso que isso não é possível, apenas se tiveres o código do dll e o meteres no projecto do executável.

PS: se tiver enganado por favor corrijam-me.

Cumps andreb

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Talvez seja, mas aviso desde já que o que vou dizer agora nunca testei...

Em tempos tive uma dúvida de uma biblioteca que uso que está cheia de componentes mas a verdade é que eu só usava um par deles. O .dll tinha 1.8Mb e se o .dll fosse compilado apenas com os componentes que eu usava certamente ficaria mais pequeno. O que me disseram foi que poderia usar o Dot Fuscator que tinha funcionalidades para remover as assemblies (e algo mais talvez) que a tua aplicação não usa.

Como disse, nunca o usei, mas suponho que se ele remove as assemblies, no fim deve criar um ficheiro .dll diferente. Se fizer isto, o mais provável é que haja a possibilidade de juntar tudo no .exe da aplicação.

Conclusão, experimenta o gajo e diz qualquer coisa  :biggrin:

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Tenho uma aplicação que utiliza uma dll é possivél eu incorporar essa dll na minha aplicação para ficar tudo num só executavél???

Possível até é (+/-) mas não tem muita lógica e dá algum trabalho.

Qual é o objectivo ?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Estava a pesquisar umas coisas para mim e consegui averiguar que existe o ILMerge que com isso podes fazer exactamente o que precisas, juntar a ssembly do biblioteca no executável.

E acho que não dá trabalho nenhum. E não tem lógica porquê? Cada um sabe sabe de si e deve ter as suas razões...

Static linking é algo que existe noutras linguagens mas não em .NET (tanto quanto eu sei) se faz lógica noutras linguagens, porque não em .NET?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Tem lógica quando queres por exemplo apenas distribuir um executável, e não um monte de ficheiros mais instaladores... Também deve reduzir o tamanho da tua aplicação, pois deve remover os assemblies que não são necessários.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Já utilizei o ILMerge e não funcionava muito bem (pelo menos nos testes que fiz). Mas agora foi à página outra vez e já tem inúmeras utilizações ... talvez funcione bem.

Uma das formas que é possível fazer (com um dll ou outro ficheiro como por exemplo um exe) é adicionar um item existente ao projecto e depois, através do reflection, gravar para como ficheiro temporário e utilizar. É necessário definir o ficheiro (dll ou outro) como “Embedded Resource” na “Build Action”. Ora no caso do DLL é necessário registá-lo após ser extraído do ficheiro original (*.exe).

A razão pela qual digo que não tem muita lógica é que um dll existe para isso mesmo: ser uma biblioteca externa e reutilizável. No caso de actualizações é mais simples substituir apenas um dll e além disso o ficheiro torna-se muito maior.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Uma das formas que é possível fazer (com um dll ou outro ficheiro como por exemplo um exe) é adicionar um item existente ao projecto e depois, através do reflection, gravar para como ficheiro temporário e utilizar. É necessário definir o ficheiro (dll ou outro) como “Embedded Resource” na “Build Action”. Ora no caso do DLL é necessário registá-lo após ser extraído do ficheiro original (*.exe).

Podes explicar isto melhor? E respondendo a citação seguinte já te explico o que quero fazer...

A razão pela qual digo que não tem muita lógica é que um dll existe para isso mesmo: ser uma biblioteca externa e reutilizável. No caso de actualizações é mais simples substituir apenas um dll e além disso o ficheiro torna-se muito maior.

Eu entendo isso mas cada um deve ter as suas razões e eu, por exemplo, tenho as minhas...

Tipo, o meu FireNotes usa uma biblioteca que ainda estou a desenvolver mas não vai estar pronta nos próximos tempos. Contudo já está funcional para ser usada pelo FireNotes. De momento está em .dll e a ser referenciado pelo FireNotes. Quando eu distribuir uma versão de testes ao público, se alguém quiser vai puder usar esse .dll mas eu queria prevenir isso. Sim eu sei, em .NET é muito fácil dar a volta ao sistema mas não vamos entrar por ai que não interessa (pelo menos para a minha situação). Já andei a pesquisar e proteger o .dll de uso sem ser através da minha aplicação talvez não seja a melhor forma. Portanto, se eu puder incluir o código do .dll no FireNotes, prefiro. Mas não o queria fazer copiando os ficheiros fonte de uma aplicação para a outro. Ao corrigir bugs na biblioteca e assim iria ter de fazer em dois ficheiros diferentes... Pelo que o que disseste na primeira citação que fiz, parece-me ser interessante mas não percebi bem...

P.S: E sim, eu sei que de qualquer maneira qualquer pessoa pode usar o .exe do FireNotes como referência e usar na mesma todos as classes/métodos que estejam expostos como públicos. Mas isso não interessa para o caso porque se ninguém souber que lá dentro tem uma biblioteca (apesar de eu estar a dizer agora :)), muito provavelmente ninguém o vai tentar usar.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Podes explicar isto melhor? E respondendo a citação seguinte já te explico o que quero fazer...

Penso que o que ele estava a dizer é que podes incorporar resources no executável (icones, imagens, sons, ficheiros de dados...). No caso de incorporares um ficheiro .DLL tens de "extrair" em run-time o ficheiro do executável e registar a biblioteca para ser usada no teu programa. Penso que era isto a que ele se referia.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Penso que o que ele estava a dizer é que podes incorporar resources no executável (icones, imagens, sons, ficheiros de dados...). No caso de incorporares um ficheiro .DLL tens de "extrair" em run-time o ficheiro do executável e registar a biblioteca para ser usada no teu programa. Penso que era isto a que ele se referia.

Correcto!

Eu entendo isso mas cada um deve ter as suas razões e eu, por exemplo, tenho as minhas...

Nazgulled, cada caso é um caso. Eu o que posso colocar no executável faço, mas se tiver uma biblioteca maior, que utilize em outros executáveis ou que acho que possa necessitar de actualizações, coloco num dll.

Em aplicações profissionais (ou grandes) existem equipas que apenas trabalham em alguns dll's(bibliotecas, usercontrols, etc)  e outras que trabalham no executável. É mais simples dividir o trabalho desta forma.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim, mas era precisamente isso que eu queria saber como se faz... Mas o que queres dizer por "extrair"? É que se for algo parecido com o que estou a pensar já não gosto da ideia lol...

Nazgulled, cada caso é um caso. Eu o que posso colocar no executável faço, mas se tiver uma biblioteca maior, que utilize em outros executáveis ou que acho que possa necessitar de actualizações, coloco num dll.

Eu sei. Mas a minha lib não está pronta para o público, quando estiver eu vou lança-la em .dll mas para já queria prevenir o uso da mesma e o que se está a falar aqui parece-me ser uma boa ideia temporária até a biblioteca ficar pronta para o público.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim, mas era precisamente isso que eu queria saber como se faz... Mas o que queres dizer por "extrair"? É que se for algo parecido com o que estou a pensar já não gosto da ideia lol...

Só um pouco que já te mostro um exemplo ... em VB  :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ora bem, não foi totalmente testado, mas acho que está a funcionar ... espero!

Criei uma função que vai extrair o ficheiro e que é chamada no form load. Coloquei um ficheiro de excel (Exemplo.xls) no programa e defini como “Embedded Resource” na “Build Action” - para ser mais simples de testar.

É mais ou menos isto:

Public Class Form1

    Private Function ExtractResourceFile(ByVal fileName As String) As String

        ' Informação da Assembly
        Dim currentAssembly As Reflection.Assembly = Reflection.Assembly.GetExecutingAssembly()

        Dim resource As String = String.Empty
        Dim fileFound As Boolean = False

        ' Lista os nomes ques estão no exe (embeded)
        Dim arrResources As String() = currentAssembly.GetManifestResourceNames()
        For Each resource In arrResources
            If resource.IndexOf(fileName) <> -1 Then
                fileFound = True
                Exit For
            End If
        Next

        ' Cas o o ficheiro exista
        If fileFound Then

            ' Cria um nome temporário (mas podes alterar)
            Dim tempPath As String = IO.Path.ChangeExtension(IO.Path.GetTempFileName(), ".xls")

            ' Lê o ficheiro
            Dim resourceStream As IO.Stream = currentAssembly.GetManifestResourceStream(resource)

            ' Cria um novo FileStream para escrever o ficheiro
            Dim writer As New IO.FileStream(tempPath, IO.FileMode.Create, IO.FileAccess.Write)

            Const size As Int16 = 4096
            Dim bytes(size) As Byte
            Dim numBytes As Int32 = 0

            ' Escreve o ficheiro para o disco
            Do
                numBytes = resourceStream.Read(bytes, 0, size)
                writer.Write(bytes, 0, numBytes)
            Loop While (numBytes > 0)

            ' Fecho das streams e limpeza dos ficheiros (memória)
            resourceStream.Close()
            resourceStream.Dispose()

            writer.Close()
            writer.Dispose()

            Return tempPath
        Else
            Return String.Empty
        End If

    End Function


    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim fileName As String = ExtractResourceFile("Exemplo.xls")
        If IO.File.Exists(fileName) Then
            Debug.WriteLine("Ficheiro criado!")
        Else
            Debug.WriteLine("O ficheiro pretendido não foi encontrado ...")
        End If
    End Sub

End Class

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Deve-me estar a escapar algo... Extrais o ficheiro da assembly, escreve-lo no disco e depois? Não fazes nada?

De qualquer maneira, se isto escreve o ficheiro no disco (ainda pensei que fosse outra coisa quando se falou em "extrair") não me serve de muito... :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Deve-me estar a escapar algo... Extrais o ficheiro da assembly, escreve-lo no disco e depois? Não fazes nada?

De qualquer maneira, se isto escreve o ficheiro no disco (ainda pensei que fosse outra coisa quando se falou em "extrair") não me serve de muito... :)

Também podes ficar com o conteúdo em memória.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Deve-me estar a escapar algo... Extrais o ficheiro da assembly, escreve-lo no disco e depois? Não fazes nada?

De qualquer maneira, se isto escreve o ficheiro no disco (ainda pensei que fosse outra coisa quando se falou em "extrair") não me serve de muito... :)

Agora só falta registares o dll.

Eu utilizei um *.xls para ver se funcionava bem, mas se utilizares um dll só tens de o registar. Coloquei nos ficheiros temporários porque acaba por ser apagado.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Pessoalmente acho pouco profissional uma aplicação de um ficheiro só! Acho que o código deve estar separado em vários ficheiros de forma a estar mais organizado e mais fácil de actualizar. Se tiveres de actualizar apenas uma biblioteca, podes fazê-lo muito simplesmente através do *.exe.

Mas é uma opinião muito discutível e que até pode ser um bocado parva.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu acho é que isso já foge ao tema, ninguém falou em aplicações de um só ficheiro (acho eu, eu pelo menos nunca falei nisso). De qualquer maneira, obrigado pelo código mas não me será útil pois pensei que fosse funcionar de forma diferente, como funciona não tenho interesse.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu acho é que isso já foge ao tema, ninguém falou em aplicações de um só ficheiro (acho eu, eu pelo menos nunca falei nisso). De qualquer maneira, obrigado pelo código mas não me será útil pois pensei que fosse funcionar de forma diferente, como funciona não tenho interesse.

Tu não ...

Tenho uma aplicação que utiliza uma dll é possivél eu incorporar essa dll na minha aplicação para ficar tudo num só executavél???

Mas é isso, tens de ver como funciona melhor para ti.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu sei ;)

Tenho que ver o ILMerge a ver se faz o que quero...

Se conseguires testar depois diz se funciona bem, ok ?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acabei por usar o ILMerge e funcionou bem... O único teste que fiz foi com o meu caso especifico, ou seja, tanto o executável principal como a biblioteca em .dll estavam em C# e foram ambos escritos por mim.

Ao autor do tópico, recomendo que testes o ILMerge porque faz exactamente o que pretendes, no fundo tens de sacar e instalar o ILMerge e fazes:

ilmerge /target:winexe /out:FicheiroFinal.exe OTeuPrograma.exe OTeuDLL.dll

E já está...

Para ajudar a que o ficheiro final tenha sempre o nome da solução, no exemplo que dei em cima, FicheiroFinal.exe acabei por adicionar o seguinte ao "Post-build" da minha solução:

"C:\Program Files\Microsoft Visual Studio 9.0\ILMerge\ILMerge.exe" /target:winexe /out:"$(TargetDir)_$(TargetFileName)" "$(TargetPath)" "$(TargetDir)CustomChrome.dll"
del "$(TargetDir)CustomChrome.dll"
del "$(TargetDir)CustomChrome.pdb"
del "$(TargetDir)$(TargetFileName)"
del "$(TargetDir)$(SolutionName).pdb"
ren "$(TargetDir)_$(TargetFileName)" $(TargetFileName)
ren "$(TargetDir)_$(SolutionName).pdb" $(SolutionName).pdb

Só tens de adaptar à tua solução...


Encontrei outra forma de fazer o que eu queria. Não tem nada a ver com o tópico mas como se também estava a discutir isso e alguém pode achar interessante...

Todas as classes e métodos public existentes na minha biblioteca, tornei-os internal, desta forma, só dentro da mesma assembly é que podem aceder a esses métodos/classes. Depois, adicionei a seguinte linha ao ficheiro AssemblyInfo:

[system.Runtime.CompilerServices.InternalsVisibleTo("NomeDaAssemblyDaAplicaçãoPrincipal")]

Assim, apenas a minha aplicação pode aceder às classes internal. Quando a biblioteca estiver pronta, basta mudar as classes necessárias de internal para public, remover a linha do ficheiro de assembly e já está.

O que acham deste método? Para aquilo que eu quero, que não é prevenir a todos os custos o uso da biblioteca é apenas para servir de "aviso" tipo "ah e tal não está pronto e não deves usar", penso que serve perfeitamente...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acabei por usar o ILMerge e funcionou bem... O único teste que fiz foi com o meu caso especifico, ou seja, tanto o executável principal como a biblioteca em .dll estavam em C# e foram ambos escritos por mim.

Ao autor do tópico, recomendo que testes o ILMerge porque faz exactamente o que pretendes, no fundo tens de sacar e instalar o ILMerge e fazes:

E já está...

Para ajudar a que o ficheiro final tenha sempre o nome da solução, no exemplo que dei em cima, FicheiroFinal.exe acabei por adicionar o seguinte ao "Post-build" da minha solução:

"C:\Program Files\Microsoft Visual Studio 9.0\ILMerge\ILMerge.exe" /target:winexe /out:"$(TargetDir)_$(TargetFileName)" "$(TargetPath)" "$(TargetDir)CustomChrome.dll"
del "$(TargetDir)CustomChrome.dll"
del "$(TargetDir)CustomChrome.pdb"
del "$(TargetDir)$(TargetFileName)"
del "$(TargetDir)$(SolutionName).pdb"
ren "$(TargetDir)_$(TargetFileName)" $(TargetFileName)
ren "$(TargetDir)_$(SolutionName).pdb" $(SolutionName).pdb

Só tens de adaptar à tua solução...

Para já não vejo aplicação para mim mas é sempre bom saber que existe esse utilitário e o que pode fazer.

Obrigado pelo feedback.

Encontrei outra forma de fazer o que eu queria. Não tem nada a ver com o tópico mas como se também estava a discutir isso e alguém pode achar interessante...

Todas as classes e métodos public existentes na minha biblioteca, tornei-os internal, desta forma, só dentro da mesma assembly é que podem aceder a esses métodos/classes. Depois, adicionei a seguinte linha ao ficheiro AssemblyInfo:

[system.Runtime.CompilerServices.InternalsVisibleTo("NomeDaAssemblyDaAplicaçãoPrincipal")]

Assim, apenas a minha aplicação pode aceder às classes internal. Quando a biblioteca estiver pronta, basta mudar as classes necessárias de internal para public, remover a linha do ficheiro de assembly e já está.

O que acham deste método? Para aquilo que eu quero, que não é prevenir a todos os custos o uso da biblioteca é apenas para servir de "aviso" tipo "ah e tal não está pronto e não deves usar", penso que serve perfeitamente...

Parece-me um boa solução ...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora