To deploy a web application, two steps are necessary:
The document describes how to deploy projects that contain Infragistics web assemblies and assumes that your project has already been deployed to a web server as an ASP.NET application. For general information about deploying ASP.NET applications, to understand Xcopy deployment, to understand Copy Project from within Visual Studio .NET, to learn about GACUTIL.EXE and for information about Windows Installer, read Microsoft Knowledge Base Article - 326355, located here:
Copy: The assemblies (files with a .dll extension) that are used in your project or for simplicity, the the entire directory contents.
C:\Program Files\Infragistics\NetAdvantage xxxx Volume x\ASP.NET\Bin (This is the installation path of the latest version of NetAdvantage on your development machine).
bin directory of your application on the production server (NOT your development machine). This will ensure that the latest assemblies are on your server and are being used by your application. You won't need to copy them again unless you put on a new release or a HotFix for an Infragistics assembly. How to handle deployment for HotFixes and how to use the BindRedirect capability in the Web.Config is discusses later in this document.
Note This assumes you as the developer do not have permissions to access the GAC on the server. If you do have access to the GAC on the production web server, for long term maintenance, it is simpler to deploy the Infragistics assemblies to the GAC and not copy them to the applications bin directory. Using the GAC, you can guarantee that all applications on the server are using the same assemblies.
Note When deploying to a hosted server where you can not add virtual directories, put the ig_common directory containing all of the Infragistics images and scripts into the root directory of your project on the server and all of the default settings will work. Otherwise, the remainder of this step describes how you can handle the image/script paths of the web elements.
When you install NetAdvantage on your development machine, the installation will automatically create these folders for you. Each web element knows where the install has placed these files, and will use that location when the page is browsed. This is great for your development machine, but most of the time your web server will not have the same folder structure as your development machine.
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections>
Add a configuration section for infragistics.web. Don't forget that this is all case sensitive! The section tag below is required, in order to add the infragistics.web tag.
<section name="infragistics.web" type="System.Configuration.SingleTagSectionHandler,System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> </configSections>
There are many advantages of using the Global Assembly Cache (GAC), however because of a few drawbacks, we have not previously installed into the GAC. When an assembly is located in the GAC, the Register Tag Prefix Directive in the ASPX page will look different. Here is what it looks like when the assembly is not in the GAC.
<%@ Register TagPrefix="iglbar" Namespace="Infragistics.WebUI.UltraWebListbar" Assembly="Infragistics.WebUI.UltraWebListbar.v2.1" %>
Here is what the Directive will look like if the Assembly has been installed into the GAC.
<%@ Register TagPrefix="iglbar" Namespace="Infragistics.WebUI.UltraWebListbar" Assembly="Infragistics.WebUI.UltraWebListbar.v2.1, Version=2.1.20042.17, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb" %>
Notice that when the Assembly has been installed into the GAC, a Full Name is used, including the Culture, Version, and PublicKeyToken for the assembly.
Upgrading now is as easy as changing the version number on the form, and placing the updated version of the assembly into the GAC. Of course if you have many pages in your web application you may want to use a BindingRedirect to your applications Web.Config file. The following would force your application to use version 2.1.20042.1018 instead of 2.1.20042.17 of UltraWebListbar.
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Infragistics.WebUI.UltraWebListbar.v2.1" publicKeyToken="7dd5c3163f2cd0cb"/> <bindingRedirect oldVersion="2.1.20042.17-2.1.20042.17" newVersion="2.1.20042.1018"/> </dependentAssembly> </assemblyBinding> </runtime>
The advantage to this approach is that now if you need to upgrade a live site, if you have applied a HotFix for example, you can do it by simply changing the version number in the binding redirect. There is no need to recompile your web application, or modify all of your webforms. If you do not have access to the GAC on the WebServer which you will be using to host your WebApplication, you can simply copy the referenced Assemblies into the
bin directory for your WebApplication, on the hosted server.
Setting CopyLocal = True for any of the Infragistics assemblies besides Infragistics.WebUI.Shared can possibly cause abnormal design-time behavior if that assembly has been installed into the GAC. Because of this, it is recommended that you do not set CopyLocal = True for any Infragistics project reference in your WebApplication, besides Infragistics.WebUI.Shared. For some Elements like WebCombo, and WebNavBar, you may get an error when trying to build and browse your page. This is likely due to Visual Studio not properly determining which additional Assemblies must be registered on that WebPage. You can either manually add the Register directive, or simply add a WebGrid and WebToolbar to your webform, and then remove them. The act of adding the Element to your Page, will force Visual Studio to add the Register Directive for you.
You can use a Directive to add Infragistics.WebUI.Shared to your page also, instead of setting CopyLocal=true. The "Assembly" Directive can be added, and would look like the following:
<%@ Assembly Name="Infragistics.WebUI.Shared.v2.1,Version=2.1.20042.16, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb" %>
Notice that this Directive is much like the Register Directive. The same rules apply here, as did for the Register Directive - a binding redirect can be added to the Web.Config to point to a different version of Infragistics.WebUI.Shared than stated in the Directive.
If your WebApplication is large, you may not want to have to add this Assembly Directive to each of your web forms. Instead, you can use the Web.Config file again. The following would specify to add Infragistics.WebUI.Shared, when compiling ASPX pages in this application.
<compilation defaultLanguage="c#" debug="true"> <assemblies> <add assembly="Infragistics.WebUI.Shared.v2.1, Version=2.1.20042.16, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb" /> </assemblies> </compilation>