Webpart Post Build .Net Automation Of Global Assembly Cache & IISRESTART
Original Article Authors: Shehzad Afzal & Jim Coutts
Date: 24th of April 2006
Contact Details: Perth & Kinross Council IS/T Services,
Carpenter House, PH1 5LZ.
Email: safzal@pkc.gov.uk
jmcoutts@pkc.gov.uk
Original problem:
Our current development environment consists of Microsoft Visual Studio .NET 2003, Sharepoint Portal Server 2003, Microsoft Framework SDK 1.1, Internet Information Services (IIS) Manager Version 6.0.
In our development environment, we found the process of making changes to webparts in .Net, then adding them to Sharepoint both convoluted and irksome.
Whenever an update is done to a webpart in .NET, Sharepoint does not automatically pickup the latest assembly. This has to be done manually in Microsoft Visual Studio 2003 development environment.
After some initial trial and error, we found the following manual process ensured the recent changes rendered in Sharepoint successfully.
When a webpart is written in .net, it is not automatically registered/updated in the global assembly cache. Also an update to the Application Pool is required; this is done by doing an IISRestart.
The manual process was as follows:
- Open Control panel, select admin tools, select Microsoft framework 1.1 configuration, click on manage the assembly cache, click on add an assembly to the assembly cache, then browse to assembly output area specified in Microsoft Visual Studio .Net 2003.
- Open control panel, select the admin tools, open Internet Information Services (IIS) Manager, right click on development environment, Click on all tasks, and click on Restart IIS.
- Refresh the browser in Internet Explorer.
However prior to this stage, it was a case of trial and error to get the changes reflected in the browser. Microsoft Framework 1.1 was not able to see the reflected changes; therefore the assembly cache needs to be added manually.
Investigation:
We found the manual process long winded and added to the overall development timescales unnecessarily.
It was agreed that there must be a way to either automate this procedure or find another efficient method that achieved the result we were looking for.
Our endeavours of finding a quick solution on the web proved unfruitful.
It was realised very early on that we would have to automate this process. The initial area we looked at was how to get IIS to refresh the application pool, without doing a manual IIS restart. After some investigation we found that the iisrestart.exe was available to run under the system32 directory. So that became quite straightforward.
However the next stage of adding the assembly cache to the application pool was a bit more painful. After some trial and error, we found that we were able to run the gacutil to register the assembly successfully.
In order to automate this whole process, we created a batch file, which incorporated these routines. It was then a simple case of creating a shortcut or link in the browser, which enable running of the batch file after a build had been completed in .Net 2003.
This meant that only a refresh on the browser was required to see the new changes taking place, and negated the need for deletion, and subsequent adding/importing a webpart after changes were made in .NET.
Conclusion:
In future versions of Microsoft Visual Studio .Net, perhaps it would be a good idea to include the functionality of the routines below, or have an option in the product, which allows the automation of both the iisrestart and gacutil operations.
The following batch file code snippet details the solution.
echo off
set /P userinput= Type the DLL name (including .dll):
set /P envinput= Type environment name (eg dev-jmc-env):
echo %userinput%
C:\windows\system32\dllcache\gacutil /i c:\inetpub\wwwroot\bin\%userinput%
rem echo %windir%\system32\iisreset.exe /noforce Dev-jmc-env
%windir%\system32\iisreset.exe /noforce %envinput%
pause
cls
