MikeB
9/17/2003 10:16:00 PM
Tal Kedem wrote:
> thanks for the answer.
>
> My problem is that I DON''T HAVE the .snk file I want to sign with.
>
> I want to produce one on the fly and then use it to sign the assembly.
> As far as I can see - al.exe doesn''t produce .snk files but only uses
> existing ones.
> The same goes for compiling and signing directly from vjc.exe with
> AssemblyKeyFile Attribute.
> Either way - you need a previously generated .snk file, and only for that
> util alone you are requested to install the .Net Framework SDK which is
> 108MB in size.
>
OK, I understand a bit better now. You can try creating a key pair
using Win32 interop with the CryptoAPI. Look at the functions
CryptDeriveKey and CryptGenKey. Using these you should be able to
create a key pair that is stored in a CSP key container.
You can specify the key container to use in your generated source code
using the AssemblyKeyNameAttribute class. Alternatively, you can invoke
al.exe using the /keyname option.
>
>
> "mikeb" <mailbox.google@mailnull.com> wrote in message
> news:OV8itVLfDHA.2576@TK2MSFTNGP11.phx.gbl...
>
>>Tal Kedem wrote:
>>
>>>Hi.
>>>
>>>My company installs some application on a client machine.
>>>Among other thing, the application should generate J# code, and build a
>>>strong-named dll from the generated code.
>>>I''ve noticed that sn.exe is a part of the .Net Framework SDK(~108MB).
>>>al.exe, for example is a part of the .Net Framework
>
> Redistributable(~23MB).
>
>>>1. Why is there a difference in the location of certain .Net tools?
>>>What''s more odd is that al.exe has a feature of signing an assembly, so
>
> why
>
>>>not supply sn.exe along with the .Net Framework Redistributable?
>>>
>>>2. Can I (legally...) install just sn.exe on the client machine instead
>
> of
>
>>>asking him to install a 108MB package that he doesn''t necessarily need?
>>>
>>>10x
>>>
>>>
>>
>>I don''t know the answers to your specific questions, but you can use the
>>al.exe program to do what you want - though you''ll end up with a
>>multi-file assembly instead of a single-file dll assembly. Just have
>>your generated J# code compiled to a netmodule, then use al.exe to
>>create the signed dll.
>>
>>The dll and netmodule files make up the assembly. As far as the
>>framework is concerned, that''s just as valid an assembly as one that''s
>>contained in a single dll file.
>>
>>mikeb
>>
>
--
mikeb