Add .NET Reference in VS 2005

Discussion in 'ASP .Net' started by Kent, Nov 14, 2005.

  1. Kent

    Kent Guest

    We have created several Assemblies that we add to the GAC on our web
    servers. In an ASP.NET app in VS2003, Adding a reference to strong named
    GAC'd Assembly meant that the web app would use whatever version was in the
    GAC.

    Now in an ASP.NET app in VS 2005, adding a reference to a GAC'd assembly
    actually adds a version specific reference to the web.config. That means
    that we would have to change the assembly reference in every single web
    application on a server? What is the point of the using the GAC to
    eliminate specific minor versions with this implementation? Back to DLL
    hell?
    Kent, Nov 14, 2005
    #1
    1. Advertising

  2. Kent

    David Browne Guest

    "Kent" <> wrote in message
    news:...
    > We have created several Assemblies that we add to the GAC on our web
    > servers. In an ASP.NET app in VS2003, Adding a reference to strong named
    > GAC'd Assembly meant that the web app would use whatever version was in
    > the GAC.
    >
    > Now in an ASP.NET app in VS 2005, adding a reference to a GAC'd assembly
    > actually adds a version specific reference to the web.config. That means
    > that we would have to change the assembly reference in every single web
    > application on a server? What is the point of the using the GAC to
    > eliminate specific minor versions with this implementation? Back to DLL
    > hell?


    Why are you changing the AssemblyVersion of your libraries if you don't want
    to break compatibility? You should keep track of builds using the
    AssemblyFileVersion and only change the AssemblyVersion when you want to
    force a recompile of dependant assemblies or allow side-by-side versions.

    David
    David Browne, Nov 14, 2005
    #2
    1. Advertising

  3. Hi Kent,

    I agree with David. The versioning behavior isn't changed since 1.1. If you
    want to the updated assemblies be considered as compatible, you should only
    modify the build or revision number.

    NET Framework Tutorials - Versioning Components
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptutorials
    /html/Binding_Policy.asp

    Please let me know if you have any special concerns.
    Thanks.

    Best regards,

    WenJun Zhang
    Microsoft Online Partner Support

    This posting is provided "AS IS" with no warranties, and confers no rights.
    WenJun Zhang[msft], Nov 15, 2005
    #3
  4. Kent

    Kent Guest

    That's not the issue. For example, in the AssemblyInfo.cs in our Utilities
    library we set the version as [assembly: AssemblyVersion("1.25.*")] where 1
    is the major version determining compatibility breaks, 25 is the revision
    for non-compatibility breaking enhancements and bug fixes, and the rest of
    the version number is the build. The Utilities library is strong named, an
    installer is built, and it is installed on all of our web servers.

    In VS 2003, adding a reference added a property Copy Local, when set to
    false would use the GACed version of the assembly. In VS 2005, at least in
    a web project, adding a reference adds an entry to the particular version,
    in this case: <assemblies><add assembly="Company.Utilities,
    Version=1.25.2090.17025, Culture=neutral,
    PublicKeyToken=C3242C516E8368B7"/></assemblies>.

    So now when I make a new build of 1.25, or up the revision to 1.26, I get
    build errors on in my web app:
    Error 2 Could not load file or assembly Company.Utilities,
    Version=1.25.2090.17025, Culture=neutral, PublicKeyToken=c3242c516e8368b7'
    or one of its dependencies. The system cannot find the file specified.
    c:\inetpub\wwwroot\webapp1\Web.config 24.

    VS 2003 paid attention to the Strong Name and pulled the assembly from the
    GAC... What's up with VS 2005? Seems like as soon as you moved the
    References to the web.config, you rendered some of the GAC functionality
    useless.



    ""WenJun Zhang[msft]"" <> wrote in message
    news:...
    > Hi Kent,
    >
    > I agree with David. The versioning behavior isn't changed since 1.1. If
    > you
    > want to the updated assemblies be considered as compatible, you should
    > only
    > modify the build or revision number.
    >
    > NET Framework Tutorials - Versioning Components
    > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptutorials
    > /html/Binding_Policy.asp
    >
    > Please let me know if you have any special concerns.
    > Thanks.
    >
    > Best regards,
    >
    > WenJun Zhang
    > Microsoft Online Partner Support
    >
    > This posting is provided "AS IS" with no warranties, and confers no
    > rights.
    >
    Kent, Nov 15, 2005
    #4
  5. Kent

    David Browne Guest

    "Kent" <> wrote in message
    news:...
    > That's not the issue. For example, in the AssemblyInfo.cs in our
    > Utilities library we set the version as [assembly:
    > AssemblyVersion("1.25.*")]
    > . . .


    That's the problem. You should never auto-increment AssemblyVersion.
    AssemblyVersion should be fixed and only changed when you want to break
    compatibility.

    David
    David Browne, Nov 15, 2005
    #5
  6. Kent

    Kent Guest

    Yeah but your missing part of the beauty of the GAC. Strong Name. I can
    have a web app compiled against Company.Utilities 1.1, but have
    Company.Utilities 1.25 installed on the web server. In our environment, we
    do not break compatibility until we move to v 2.

    When we add functions and classes or perform bug fixes (which can be
    frequent), we up the revision number (all changes are backwards compatible).
    The final build before an release is packaged into an installer and
    installed on all of our web servers. If a developer wants to take advantage
    of the new classes, they can install the new version of the assembly and
    build against it. We do not install multiple revision versions of an
    assembly (1.24, 1.25 etc.) on the servers, just major versions (v1., v2.,
    etc.), I hope I am making sense.

    In our environment, to break every one of our web apps, services, etc
    (100's of them) would be insane. This paradigm worked in VS 2003. This
    paradigm works in VS 2005 in a Windows Application (has the References tree
    with all of the properties in Solution Explorer). Why will this not work in
    VS 2005 on a Web Application?? That is the problem.

    Thank you for your help...

    "David Browne" <davidbaxterbrowne no potted > wrote in
    message news:...
    >
    > "Kent" <> wrote in message
    > news:...
    >> That's not the issue. For example, in the AssemblyInfo.cs in our
    >> Utilities library we set the version as [assembly:
    >> AssemblyVersion("1.25.*")]
    >> . . .

    >
    > That's the problem. You should never auto-increment AssemblyVersion.
    > AssemblyVersion should be fixed and only changed when you want to break
    > compatibility.
    >
    > David
    >
    >
    >
    >
    >
    Kent, Nov 15, 2005
    #6
  7. re:
    > Why will this not work in VS 2005 on a Web Application?? That is the problem.


    You can get around that limitation by using this tool :
    the "Visual Studio 2005 Web Deployment Projects" Add-in for VS 2005,
    which is available *now* at :

    http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

    "This add-in includes a new tool that enables you to merge the assemblies
    created during ASP.NET 2.0 precompilation, and it provides a comprehensive
    UI within Visual Studio 2005 for managing build configurations, merging,
    and pre-build and post-build task using MSBuild."

    "A Web Deployment Project creates and maintains an MSBuild project file,
    and is associated in a solution with a Web site project.

    A Web Deployment Project enables you to manage not only build configuration
    and merge options, but other tasks such as specifying changes for the application's
    Web.config file during compilation, changing connection strings, creating virtual
    directories, and performing other tasks at specific points in the deployment process.

    The new assembly merge tool (Aspnet_merge.exe) combines assemblies created
    during ASP.NET 2.0 precompilation for deployment. The tool supports many merge
    options, from combining assemblies for each Web site folder to creating a single
    assembly for the entire Web site."

    Don't forget to download these very helpful documents :

    "Using Web Deployment Projects with Visual Studio 2005"
    http://go.microsoft.com/fwlink/?LinkId=55638
    and
    "Managing ASP.NET Pre-compiled Outputs with Aspnet_merge.exe Command"
    http://go.microsoft.com/fwlink/?LinkId=55639

    Read Scott Guthrie's description of the tool :
    http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx

    If you run into problems with the tool, post them to :
    http://forums.asp.net/138/ShowForum.aspx




    Juan T. Llibre, ASP.NET MVP
    ASP.NET FAQ : http://asp.net.do/faq/
    ASPNETFAQ.COM : http://www.aspnetfaq.com/
    Foros de ASP.NET en Español : http://asp.net.do/foros/
    ======================================
    "Kent" <> wrote in message
    news:...
    > Yeah but your missing part of the beauty of the GAC. Strong Name. I can have a web app
    > compiled against Company.Utilities 1.1, but have Company.Utilities 1.25 installed on the
    > web server. In our environment, we do not break compatibility until we move to v 2.
    >
    > When we add functions and classes or perform bug fixes (which can be frequent), we up
    > the revision number (all changes are backwards compatible). The final build before an
    > release is packaged into an installer and installed on all of our web servers. If a
    > developer wants to take advantage of the new classes, they can install the new version
    > of the assembly and build against it. We do not install multiple revision versions of
    > an assembly (1.24, 1.25 etc.) on the servers, just major versions (v1., v2., etc.), I
    > hope I am making sense.
    >
    > In our environment, to break every one of our web apps, services, etc (100's of them)
    > would be insane. This paradigm worked in VS 2003. This paradigm works in VS 2005 in a
    > Windows Application (has the References tree with all of the properties in Solution
    > Explorer). Why will this not work in VS 2005 on a Web Application?? That is the
    > problem.
    >
    > Thank you for your help...
    >
    > "David Browne" <davidbaxterbrowne no potted > wrote in message
    > news:...
    >>
    >> "Kent" <> wrote in message
    >> news:...
    >>> That's not the issue. For example, in the AssemblyInfo.cs in our Utilities library we
    >>> set the version as [assembly: AssemblyVersion("1.25.*")]
    >>> . . .

    >>
    >> That's the problem. You should never auto-increment AssemblyVersion. AssemblyVersion
    >> should be fixed and only changed when you want to break compatibility.
    >>
    >> David
    >>
    >>
    >>
    >>
    >>

    >
    >
    Juan T. Llibre, Nov 15, 2005
    #7
  8. Kent

    Kent Guest

    The deployment tool looks cool and all but I don't want to merge the
    assemblies, but is useless to me in that I want the web application to use
    the assembly version GACd on the server. I want all of the web sites on
    that server using the GACd version. Using this deployment thing would mean
    once again, rebuilding every single web app... retarded. I don't just have
    one assembly like this... I have several...

    I can add a class library to the solution that my web project is in and the
    references in there act just like in VS 2003... Why did they decide the
    treat the Web project references differently. They might as well just copy
    the dll local and forget the GAC altogether for web projects.

    This is a very simple concept. When they moved the references into the
    web.config in 2005, they broke this for me... They did not break this in
    non-web projects... What gives?


    "Juan T. Llibre" <> wrote in message
    news:%...
    > re:
    >> Why will this not work in VS 2005 on a Web Application?? That is the
    >> problem.

    >
    > You can get around that limitation by using this tool :
    > the "Visual Studio 2005 Web Deployment Projects" Add-in for VS 2005,
    > which is available *now* at :
    >
    > http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx
    >
    > "This add-in includes a new tool that enables you to merge the assemblies
    > created during ASP.NET 2.0 precompilation, and it provides a comprehensive
    > UI within Visual Studio 2005 for managing build configurations, merging,
    > and pre-build and post-build task using MSBuild."
    >
    > "A Web Deployment Project creates and maintains an MSBuild project file,
    > and is associated in a solution with a Web site project.
    >
    > A Web Deployment Project enables you to manage not only build
    > configuration
    > and merge options, but other tasks such as specifying changes for the
    > application's
    > Web.config file during compilation, changing connection strings, creating
    > virtual
    > directories, and performing other tasks at specific points in the
    > deployment process.
    >
    > The new assembly merge tool (Aspnet_merge.exe) combines assemblies created
    > during ASP.NET 2.0 precompilation for deployment. The tool supports many
    > merge
    > options, from combining assemblies for each Web site folder to creating a
    > single
    > assembly for the entire Web site."
    >
    > Don't forget to download these very helpful documents :
    >
    > "Using Web Deployment Projects with Visual Studio 2005"
    > http://go.microsoft.com/fwlink/?LinkId=55638
    > and
    > "Managing ASP.NET Pre-compiled Outputs with Aspnet_merge.exe Command"
    > http://go.microsoft.com/fwlink/?LinkId=55639
    >
    > Read Scott Guthrie's description of the tool :
    > http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx
    >
    > If you run into problems with the tool, post them to :
    > http://forums.asp.net/138/ShowForum.aspx
    >
    >
    >
    >
    > Juan T. Llibre, ASP.NET MVP
    > ASP.NET FAQ : http://asp.net.do/faq/
    > ASPNETFAQ.COM : http://www.aspnetfaq.com/
    > Foros de ASP.NET en Español : http://asp.net.do/foros/
    > ======================================
    > "Kent" <> wrote in message
    > news:...
    >> Yeah but your missing part of the beauty of the GAC. Strong Name. I can
    >> have a web app compiled against Company.Utilities 1.1, but have
    >> Company.Utilities 1.25 installed on the web server. In our environment,
    >> we do not break compatibility until we move to v 2.
    >>
    >> When we add functions and classes or perform bug fixes (which can be
    >> frequent), we up the revision number (all changes are backwards
    >> compatible). The final build before an release is packaged into an
    >> installer and installed on all of our web servers. If a developer wants
    >> to take advantage of the new classes, they can install the new version of
    >> the assembly and build against it. We do not install multiple revision
    >> versions of an assembly (1.24, 1.25 etc.) on the servers, just major
    >> versions (v1., v2., etc.), I hope I am making sense.
    >>
    >> In our environment, to break every one of our web apps, services, etc
    >> (100's of them) would be insane. This paradigm worked in VS 2003. This
    >> paradigm works in VS 2005 in a Windows Application (has the References
    >> tree with all of the properties in Solution Explorer). Why will this not
    >> work in VS 2005 on a Web Application?? That is the problem.
    >>
    >> Thank you for your help...
    >>
    >> "David Browne" <davidbaxterbrowne no potted > wrote in
    >> message news:...
    >>>
    >>> "Kent" <> wrote in message
    >>> news:...
    >>>> That's not the issue. For example, in the AssemblyInfo.cs in our
    >>>> Utilities library we set the version as [assembly:
    >>>> AssemblyVersion("1.25.*")]
    >>>> . . .
    >>>
    >>> That's the problem. You should never auto-increment AssemblyVersion.
    >>> AssemblyVersion should be fixed and only changed when you want to break
    >>> compatibility.
    >>>
    >>> David
    >>>
    >>>
    >>>
    >>>
    >>>

    >>
    >>

    >
    >
    Kent, Nov 15, 2005
    #8
  9. Kent

    David Browne Guest

    "Kent" <> wrote in message
    news:...
    > Yeah but your missing part of the beauty of the GAC. Strong Name. I can
    > have a web app compiled against Company.Utilities 1.1, but have
    > Company.Utilities 1.25 installed on the web server. In our environment,
    > we do not break compatibility until we move to v 2.


    Strong names always contain a version, always did. You're swimming up
    stream by pretending that some changes in AssemblyVerson don't "break
    compatibility". They always did, always will. If you let VS autoincrement
    your AssemblyVersion then you can have multiple versions of each assembly in
    the GAC, and it can be very tricky to determine which version you are
    actually running.

    Perhaps you can work around this using assembly redirection:

    http://msdn.microsoft.com/library/d...uide/html/cpconassemblyversionredirection.asp

    With a policy you can specify that any assembly compiled against
    Company.Utilities 1.1 should load 1.25 instead.


    David
    David Browne, Nov 16, 2005
    #9
  10. re:
    > The deployment tool looks cool and all but I don't want to merge the assemblies


    Sorry, I thought you meant the generated assemblies for the pages,
    not the pre-compiled ones.

    re:
    > I want the web application to use the assembly version GACd on the server.


    You're always able to use particular strong-named
    assemblies in the GAC, aren't you ?

    You need to prevent VS from auto-incrementing version numbers, though,
    unless you want to wind up with a mess in the GAC, with multiple versions
    of your assembly, and you going nuts assigning particular versions to
    your applications.




    Juan T. Llibre, ASP.NET MVP
    ASP.NET FAQ : http://asp.net.do/faq/
    ASPNETFAQ.COM : http://www.aspnetfaq.com/
    Foros de ASP.NET en Español : http://asp.net.do/foros/
    ======================================
    "Kent" <> wrote in message
    news:...
    > The deployment tool looks cool and all but I don't want to merge the assemblies, but is
    > useless to me in that I want the web application to use the assembly version GACd on the
    > server. I want all of the web sites on that server using the GACd version. Using this
    > deployment thing would mean once again, rebuilding every single web app... retarded. I
    > don't just have one assembly like this... I have several...
    >
    > I can add a class library to the solution that my web project is in and the references
    > in there act just like in VS 2003... Why did they decide the treat the Web project
    > references differently. They might as well just copy the dll local and forget the GAC
    > altogether for web projects.
    >
    > This is a very simple concept. When they moved the references into the web.config in
    > 2005, they broke this for me... They did not break this in non-web projects... What
    > gives?
    >
    >
    > "Juan T. Llibre" <> wrote in message
    > news:%...
    >> re:
    >>> Why will this not work in VS 2005 on a Web Application?? That is the problem.

    >>
    >> You can get around that limitation by using this tool :
    >> the "Visual Studio 2005 Web Deployment Projects" Add-in for VS 2005,
    >> which is available *now* at :
    >>
    >> http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx
    >>
    >> "This add-in includes a new tool that enables you to merge the assemblies
    >> created during ASP.NET 2.0 precompilation, and it provides a comprehensive
    >> UI within Visual Studio 2005 for managing build configurations, merging,
    >> and pre-build and post-build task using MSBuild."
    >>
    >> "A Web Deployment Project creates and maintains an MSBuild project file,
    >> and is associated in a solution with a Web site project.
    >>
    >> A Web Deployment Project enables you to manage not only build configuration
    >> and merge options, but other tasks such as specifying changes for the application's
    >> Web.config file during compilation, changing connection strings, creating virtual
    >> directories, and performing other tasks at specific points in the deployment process.
    >>
    >> The new assembly merge tool (Aspnet_merge.exe) combines assemblies created
    >> during ASP.NET 2.0 precompilation for deployment. The tool supports many merge
    >> options, from combining assemblies for each Web site folder to creating a single
    >> assembly for the entire Web site."
    >>
    >> Don't forget to download these very helpful documents :
    >>
    >> "Using Web Deployment Projects with Visual Studio 2005"
    >> http://go.microsoft.com/fwlink/?LinkId=55638
    >> and
    >> "Managing ASP.NET Pre-compiled Outputs with Aspnet_merge.exe Command"
    >> http://go.microsoft.com/fwlink/?LinkId=55639
    >>
    >> Read Scott Guthrie's description of the tool :
    >> http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx
    >>
    >> If you run into problems with the tool, post them to :
    >> http://forums.asp.net/138/ShowForum.aspx
    >>
    >>
    >>
    >>
    >> Juan T. Llibre, ASP.NET MVP
    >> ASP.NET FAQ : http://asp.net.do/faq/
    >> ASPNETFAQ.COM : http://www.aspnetfaq.com/
    >> Foros de ASP.NET en Español : http://asp.net.do/foros/
    >> ======================================
    >> "Kent" <> wrote in message
    >> news:...
    >>> Yeah but your missing part of the beauty of the GAC. Strong Name. I can have a web
    >>> app compiled against Company.Utilities 1.1, but have Company.Utilities 1.25 installed
    >>> on the web server. In our environment, we do not break compatibility until we move to
    >>> v 2.
    >>>
    >>> When we add functions and classes or perform bug fixes (which can be frequent), we up
    >>> the revision number (all changes are backwards compatible). The final build before an
    >>> release is packaged into an installer and installed on all of our web servers. If a
    >>> developer wants to take advantage of the new classes, they can install the new version
    >>> of the assembly and build against it. We do not install multiple revision versions of
    >>> an assembly (1.24, 1.25 etc.) on the servers, just major versions (v1., v2., etc.), I
    >>> hope I am making sense.
    >>>
    >>> In our environment, to break every one of our web apps, services, etc (100's of them)
    >>> would be insane. This paradigm worked in VS 2003. This paradigm works in VS 2005 in
    >>> a Windows Application (has the References tree with all of the properties in Solution
    >>> Explorer). Why will this not work in VS 2005 on a Web Application?? That is the
    >>> problem.
    >>>
    >>> Thank you for your help...
    >>>
    >>> "David Browne" <davidbaxterbrowne no potted > wrote in message
    >>> news:...
    >>>>
    >>>> "Kent" <> wrote in message
    >>>> news:...
    >>>>> That's not the issue. For example, in the AssemblyInfo.cs in our Utilities library
    >>>>> we set the version as [assembly: AssemblyVersion("1.25.*")]
    >>>>> . . .
    >>>>
    >>>> That's the problem. You should never auto-increment AssemblyVersion. AssemblyVersion
    >>>> should be fixed and only changed when you want to break compatibility.
    >>>>
    >>>> David
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>>

    >>
    >>

    >
    >
    Juan T. Llibre, Nov 16, 2005
    #10
  11. Hi Kent,

    I'd correct that built-in assemblies with different build or revision
    number are treated compatible but this doesn't apply to custom assembly.
    The version number need to exactly match for adding reference of custom
    strong named assembly.

    Thanks.

    Best regards,

    WenJun Zhang
    Microsoft Online Partner Support

    This posting is provided "AS IS" with no warranties, and confers no rights.
    WenJun Zhang[msft], Nov 16, 2005
    #11
  12. Kent

    Kent Guest

    Figured it out (with the help of a colleage that set these intra-company
    assemblies up originally). Actually, we had to change the installer to add
    this assembly to the configured assemblies.

    We added this entry to the 2.0 machine.config:

    <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
    <assemblyIdentity name="Company.Utilities"
    publicKeyToken="c3242c516e8368b7" />
    <bindingRedirect oldVersion="1.0.0.0-1.65535.65535.65535"
    newVersion="1.25.2146.29614" />
    </dependentAssembly>
    </assemblyBinding>
    </runtime>

    This will redirect any call with the same Major version
    (Major.Minor.Build.Revision). We set the Major and Minor version in the
    assemblies and let the Build and Revision auto-increment. We have this need
    because the assemblies are constantly being enhanced and many, many internal
    applications use them (web, client, services, etc.). We are just careful to
    not break compatibility within a Major version (through Unit testing and
    Regression testing).

    Thanks.
    Kent, Nov 16, 2005
    #12
  13. Kent

    Guest

    You guys are missing the point. We dont' want work arounds,
    redirections, deployment tools. Strong names, side-by-side execution,
    deployment to the GAC are fundamental features of .Net. The new
    Asp.net model has missed the mark.

    If you disagree with my statement, I challenge you to create a
    strongly-named assembly from an Asp.net project (remember a strong name
    must have assembly, version, culture and public key token). It is
    currently not possible. You'll find you cannot specify the version
    anywhere and you'll never get that assembly into the GAC.

    The workaround I'm considering is to put all of my web "code behind"
    logic into a separate class library that is strongly named. Then in my
    pages I use strong references and remove the CodeFile attribute
    completely.

    Pre-compliation is a great idea, I just wish they would enable you to
    pre-compile an entire site into a single assembly that is strongly
    named. It should be a basic feature of Asp.net. At a minimum, I need
    my code-behind logic to be in a single, strongly named assembly that I
    can put into the GAC.

    John Powell
    , Dec 5, 2005
    #13
  14. Kent

    David Browne Guest

    <> wrote in message
    news:...
    > You guys are missing the point. We dont' want work arounds,
    > redirections, deployment tools. Strong names, side-by-side execution,
    > deployment to the GAC are fundamental features of .Net. The new
    > Asp.net model has missed the mark.
    >
    > If you disagree with my statement, I challenge you to create a
    > strongly-named assembly from an Asp.net project (remember a strong name
    > must have assembly, version, culture and public key token). It is
    > currently not possible. You'll find you cannot specify the version
    > anywhere and you'll never get that assembly into the GAC.


    The generated assembly has AssemblyVersion 0.0.0.0 and can be installed in
    the GAC. You just need to use the full name in the page inherits attribute.
    EG:


    <%@ page language="C#" autoeventwireup="true" inherits="Default2,
    App_Web_default2.aspx.cdcab7d2, Version=0.0.0.0, Culture=neutral,
    PublicKeyToken=c6fdb90a2f52777d" %>

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

    <html xmlns="http://www.w3.org/1999/xhtml" >
    <head runat="server">
    <title>Untitled Page</title>
    </head>
    <body>
    <form id="form1" runat="server">
    <div>
    <asp:Button ID="Button1" runat="server" OnClick="Button1_Click"
    Text="Button" /></div>
    </form>
    </body>
    </html>


    > The workaround I'm considering is to put all of my web "code behind"
    > logic into a separate class library that is strongly named. Then in my
    > pages I use strong references and remove the CodeFile attribute
    > completely.
    >
    > Pre-compliation is a great idea, I just wish they would enable you to
    > pre-compile an entire site into a single assembly that is strongly
    > named. It should be a basic feature of Asp.net. At a minimum, I need
    > my code-behind logic to be in a single, strongly named assembly that I
    > can put into the GAC.
    >



    But that wasn't the OP's problem at all. He had some strong named common
    libraries (not code behind). He was having problems referencing them since
    he was auto-incrementing the Assembly Versions.

    So back to your post. You appear to want to put your code behind in the
    GAC. Why? Code-behind is inherently application-specific, tightly-bound to
    the ASPX, and full of click handlers and references to the controls on a
    Page. Why would you want to deploy it to a server-wide location?

    You can factor out business logic to shared assemblies which you are free to
    GAC, but I don't see the advantage of installing your GUI click handlers in
    the GAC.

    David
    David Browne, Dec 5, 2005
    #14
  15. Kent

    Guest

    David,

    The reason I want my code-behind in the GAC is for deployment. We have
    user controls and pages running in a customized SharePoint portal.
    SharePoint has several different applications and hence several bin
    directories. It was very simple to maintain a single assembly in the
    GAC rather than having multiple copies in each bin directory.

    Have you actually tried putting a precompiled assembly in the GAC? It
    wouldn't go for me, and I assumed this is because 0.0.0.0 doesn't
    qualify as a version.

    John
    , Dec 6, 2005
    #15
  16. Kent

    David Browne Guest

    <> wrote in message
    news:...
    > David,
    >
    > The reason I want my code-behind in the GAC is for deployment. We have
    > user controls and pages running in a customized SharePoint portal.
    > SharePoint has several different applications and hence several bin
    > directories. It was very simple to maintain a single assembly in the
    > GAC rather than having multiple copies in each bin directory.
    >
    > Have you actually tried putting a precompiled assembly in the GAC? It
    > wouldn't go for me, and I assumed this is because 0.0.0.0 doesn't
    > qualify as a version.
    >


    Yes, I tested it. I set the project properties to generate strong named
    assemblies, added a key file and precompiled the site. Then I GAC'd the
    assemblies. Then I copied the site to another folder and deleted the
    assemblies in the \bin folder and created a new virtual directory pointing
    to the application folder.

    David
    David Browne, Dec 6, 2005
    #16
  17. Kent

    Guest

    David,

    I figured out why I was unable to install the assembly into the GAC. I
    was trying to use the 1.1 MMC snap-in. Looks like the 2.0 snap-in is
    not installed with the 2.0 redistributable only the SDK. I ended up
    using the command line and that worked.

    I still have a hang-up with VS.Net enabling you to create strongly
    named assemblies but not giving you the ability to control the assembly
    name and version. Other people probably has a good case for installing
    web application assemblies into the GAC (running side-by-side,
    deployment convenience, etc).

    John Powell
    , Dec 7, 2005
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Juan T. Llibre
    Replies:
    0
    Views:
    436
    Juan T. Llibre
    Jun 7, 2005
  2. ce
    Replies:
    1
    Views:
    2,958
  3. Sql Agentman
    Replies:
    0
    Views:
    634
    Sql Agentman
    Jan 19, 2006
  4. =?Utf-8?B?S2VpdGggQ2xlZ2c=?=

    Cannpot seem to add a reference in Visual Studio 2005

    =?Utf-8?B?S2VpdGggQ2xlZ2c=?=, Sep 8, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    377
    Cowboy \(Gregory A. Beamer\)
    Sep 8, 2006
  5. dipesh
    Replies:
    0
    Views:
    133
    dipesh
    Jan 26, 2006
Loading...

Share This Page