Quick Tip
Change Is Good
Web Part Post-build .NET Automation of Global Assembly Cache and IISRestart
By Shehzad Afzal and Jim Coutts
Original Problem
Our current development environment consists of Microsoft Visual Studio .NET 2003, SharePoint Portal Server 2003, Microsoft Framework SDK 1.1, and Internet Information Services (IIS) Manager Version 6.0. In our development environment, we found the process of making changes to Web parts in .NET then adding them to SharePoint both convoluted and irksome.
Whenever an update is done to a Web part in .NET, SharePoint does not automatically pick up the latest assembly. This has to be done manually in the 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 Web part 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:
1) Open Control Panel, select Administrative 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 the assembly output area specified in Microsoft Visual Studio .NET 2003.
2) Open Control Panel, select Administrative Tools, open Internet Information Services (IIS) Manager, right click on Development Environment, click on All Tasks, and click Restart IIS.
3) Refresh the browser in Internet Explorer.
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 longwinded and unnecessarily added to the overall development time. We agreed that there must be a way to either automate this procedure or find another efficient method that achieved the desired result. Our endeavours of finding a quick solution on the Web proved fruitless.
We realized 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.
To automate this whole process, we created a batch file that incorporated these routines. It was then a simple case of creating a shortcut or link in the browser, which enables running a batch file after a build had been completed in .NET 2003. 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
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 of a Web part after changes were made in .NET.
Conclusion
In future versions of Microsoft Visual Studio .NET, perhaps it would be a good idea to include this functionality, or have an option in the product that allows the automation of both the IISRestart and gacutil operations.
Shehzad Afzal and Jim Coutts work for Perth & Kinross Council IS/T Services. You can reach them via e-mail at mailto:[email protected] and mailto:[email protected].
