|
|
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:
http://support.microsoft.com/default.aspx?scid=kb;en-us;326355&Product=aspnet.
Copy: The assemblies (files with a .dll extension) that are used in your project or for simplicity, the the entire directory contents.
From:
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).
To: Your 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.
Many times, your development environment is not set up the same way as your web server. This becomes evident when it comes time to deploy the web application you've spent so much time working on. Unfortunately, because of the dependencies on JavaScript files which provide all client side functionality, simply x-copying your web application to your web server is not enough; you need to also put the JavaScript files and any images, into the proper path on your web server.
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.
In order to allow you to change where the web elements look to find their JavaScript files, properties were added for JavaScriptFileName and ImageDirectory. These properties can be used to configure your web application to match the configuration of your Web Server. The drawback of this approach is scalability. As your web applications get larger, so does the task of changing these properties on each Web Element. This also means that if for some reason you move the script or image resources on your web server, then you must recompile your web application with the modified JavaScriptFileName and ImageDirectory properties.
Configuration files in .NET are used to supply additional settings to an application, which can be modified without recompiling your application. You can now specify the JavaScriptDirectory and ImageDirectory for all Infragistics web elements in a Web.Config file. The value specified in the config file will override any values set on the control, making it possible to change the location of JavaScript files and image files for all Infragistics web elements in your web application, with out having to rebuild.
There are two tags that need to be added to your Web.Config file. The first tag is a section tag, which specifies that infragistics.web is indeed a valid element for the Web.Config file. After adding the section tag, you can then add the actual infragistics.web tag. The following is an example of a Web.Config file which specifies the values JavaScriptDirectory and ImageDirectory. In this example, all Web Elements are pointed to the Application's scripts and images folders.
<?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>Now that we have added the section tag, we can add the infragistics.web tag, with out the framework complaining. We will specify two properties here, imageDirectory and javaScriptDirectory. Both of these properties are rooted at the current application directory, specified by ~/. You do not have to specify both properties; you can specify javaScriptDirectory, with out specifying imageDirectory. Also note that the property sepcifies the javaScriptDirectory, not a specific path to a file. All Infragistics Web Elements JavaScript files should reside in the directory specified here. This includes the common script file (ig_csom.js).
<infragistics.web imageDirectory="~/images" javaScriptDirectory="~/scripts"/>
<system.web>
<compilation
defaultLanguage="c#"
debug="true"
/>
-->
<customErrors
mode="RemoteOnly"
/>
<authentication mode="Windows" />
<trace
enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
localOnly="true"
/>
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="20"
/>
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
/>
</system.web>
</configuration>
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>