Add .NET Reference in VS 2005

[Kent]

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?

 

[David Browne]

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

 

[WenJun Zhang[msft]]

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]

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.

 

[David Browne]

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]

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...

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]

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

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...

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]

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?

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

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...

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]

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

 

[Juan T. Llibre]

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.

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?

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

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...


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

 

[WenJun Zhang[msft]]

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.

 

[Kent]

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.

 

[john]

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

 

[David Browne]

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>

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

 

[john]

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

 

[David Browne]

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

 

[john]

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