Re: Delayed Signing, the GAC, and Installations

From: Nicole Calinoiu (calinoiu)
Date: 11/13/04

  • Next message: Steven Cheng[MSFT]: "Re: Why i cannot write a file, even i add a permission to that file."
    Date: Sat, 13 Nov 2004 15:18:37 -0500
    
    

    "Bill" <nospam@devdex.com> wrote in message
    news:uUHs4WEyEHA.3224@TK2MSFTNGP14.phx.gbl...
    > Todd, you make a good point and that may be what I do. Thanks.
    >
    > Nicole, I also see your point, and I'd like to get more information from
    > you. I'm guessing that the development team should not be responsible
    > for signing the assemblies. They should use delay-signing with the
    > public key, and then QA or whatever team is responsible for testing
    > should handle the signing of the assemblies before generating the
    > Installation packages.

    Well, that all depends on your process and who you think can be trusted with
    the private key. Personally, I think it's a wee bit odd to have QA either
    signing assemblies or generating installation packages, but maybe it makes
    sense in your organization.

    To be honest, I'm also not quite sure why you object to manually building up
    the content list for a setup project. It's a bit more work (say, maybe 1/2
    an hour more for a medium-large project), but this extra work only needs to
    be done once, and the extra control over package content can sometimes save
    time troubleshooting later on. I've been creating setup projects this way
    for quite some time now, and I really don't see it as much bother at all.

    > If that's the case, how can I work the eventual
    > signing of the assemblies by QA into an automated build process? I am
    > using BuildIt
    > (http://msdn.microsoft.com/library/en-us/dnbda/html/tdlg_app.asp?frame=t
    > rue) to automate the build. Todd's sugguestion would work but it would
    > also make the signing part of the development process which, like you
    > said, goes against the goal of delay-signing.

    Again, the whole setup seems a wee bit odd to me, but I guess it depends on
    the role of QA in your organization. In mine, QA works against installed
    applications in order to ensure that both the applications and their
    installation-time configurations are tested. QA would never need to compile
    or sign an application, nor would they build installation packages.

    >
    > Thanks guys!
    >
    > *** Sent via Developersdex http://www.developersdex.com ***
    > Don't just participate in USENET...get rewarded for it!


  • Next message: Steven Cheng[MSFT]: "Re: Why i cannot write a file, even i add a permission to that file."

    Relevant Pages

    • RE: Installing a delayed-signed assembly into the GAC
      ... What you can do to use project output is do the signing in the post build ... setup project however it will be signed before it is included in the setup ... >assemblies, and I'd like to use delay-signing to get the benefits it ... >installation fails when it tries to add the assembly to the GAC ...
      (microsoft.public.vsnet.setup)
    • Re: Sharing Code
      ... But this is a red-herring you've thrown in and really has nothing to do with the general precept and good practice of signing any assembly you create because it is *the easiest thing to do* when creating the most flexible of assemblies. ... How are you making it sound oh so time consuming to add a reference to a key file when you know damn well it takes seconds, which in any normal developer's book is zero-effort. ... in order to avoid warnings I moved the signing from AssemblyInfo to the properties pane. ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: strong name error
      ... Conditionally signing of assemblies is still possible, ... Remove all assembly-level attributes previously used to specify signing ... Specify your preferred signing behaviour for release builds using the ...
      (microsoft.public.dotnet.framework)
    • Re: Run app from network share
      ... For this, and to run applications in the security zone of network shares, we're signing our .NET assemblies with a strong key that is shared by all products from our company. ...
      (microsoft.public.dotnet.framework)
    • Re: Sharing Code
      ... You seem to assume I don't know how VS works with key files, yet I'm the one who has been signing all of his assemblies for seven years now. ... If you don't want it to copy the file like that (and this is nothing specific to the key file, all the files work this way in VS) then you first must make a link to your key file from within your project. ... I've run into the problem where a production assembly being signed means that a unit test assembly needs to be signed too, if you want to use InternalsVisibleTo. ...
      (microsoft.public.dotnet.languages.csharp)