Request a topic or
contact an Arke consultant
404-812-3123
Arke Systems Blog - SharePoint

Arke Systems Blog

Useful technical and business information straight from Arke.

About the author

Author Name is someone.
E-mail me Send mail

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010

Deploying IIS dlls, part 2

Following up on my previous post about copying some CRM Plugin DLLs after a build ( http://arkesystems.com/blog/post/2009/02/Recycling-IIS-app-pools.aspx ):

It turns out that the error checking in post-build events isn't reliable (it only checks errorlevel at the end of the script), and apppools don't stop instantly even when told to stop instead of recycle. 

So if my xcopy encounters a "sharing violation" (errorlevel 4) then the post-build event isn't smart enough to notice by default.

Luckily, it's just a bat file, so we can add some checking ourselves.  This is getting more complicated than I would like, but at least I build reliably now.

"sleep" isn't necessary, but it's a useful command to have around.  It comes with Windows 2003 Server Resource Kit: http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en ; restart visual studio after installing the kit.

A note on checking return codes in batch files: Equality checks are actually 'greater than or equal', so you will see people checking if errorlevel eq 1 often.  However, this only catches >= 1 error levels, and the occassional program that returns negative error codes will slip past.  Accordingly, always check "neq 0" instead of "eq 1".  Also, using "SETLOCAL ENABLEDELAYEDEXPANSION" and !ERORRLEVEL! is not strictly necessary in this script, but it's good practice to just always use delayed expansion when checking return values in batch files so that you don't screw up one day when you write an error check inside a loop.

So, hopefully my final iteration of a post-build script that needs to update some IIS dlls:

SETLOCAL ENABLEDELAYEDEXPANSION
net pause KeepAliveService
cscript /nologo "$(ProjectDir)\iis_stop_app_pool.vbs" "CRMAppPool"
if !ERRORLEVEL! NEQ 0 GOTO FAIL
set CRMDIR=C:\Program Files\Microsoft Dynamics CRM
set loop=0
:TRYCOPY
set /a loop=%loop%+1
xcopy "$(TargetPath)" "%CRMDIR%\Server\bin\assembly" /i /d /y
if !ERRORLEVEL! NEQ 0 GOTO COPYFAIL
xcopy "$(TargetDir)$(TargetName).pdb" "%CRMDIR%\Server\bin\assembly" /i /d /y
if !ERRORLEVEL! NEQ 0 GOTO COPYFAIL
cscript /nologo "$(ProjectDir)\iis_start_app_pool.vbs" "CRMAppPool"
if !ERRORLEVEL! NEQ 0 GOTO FAIL
net continue KeepAliveService
GOTO OK
:COPYFAIL
if %LOOP% LEQ 10 GOTO TRYCOPYSLEEP
goto FAIL
:TRYCOPYSLEEP
sleep 1
goto TRYCOPY
:FAIL
echo "Failed with errorlevel !ERRORLEVEL!"
exit 1
:OK
echo "OK"

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by David Eison on Friday, February 27, 2009 5:23 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Recycling IIS app pools

When developing for Sharepoint or working on CRM DLLs, you need to recycle the IIS app pool a fair bit.

 

Maybe I’m late to the party and everyone already knows this, but just in case, this utility for resetting iis app pools rocks: http://www.harbar.net/articles/APM.aspx 

 

You can also recycle an app pool in a script with

cscript c:\windows\system32\iisapp.vbs /a "CRMAppPool" /r 

But, for my CRM DLL, I need a post-build event that stops the app pool before I copy a DLL.  I tried simply using iisapp.vbs to recycle, but this failed sometimes because the DLL can still be in use after the restart (I'm not sure if it restarts too fast, or if it due to overlapped recycling).

Based on posts from http://mscrm4ever.blogspot.com/2008/12/expediting-plug-in-development-using-vs.html and http://www.experts-exchange.com/Programming/Languages/Visual_Basic/Q_21362452.html , I ended up with the below.

My post-build event:

cscript /nologo "$(ProjectDir)\iis_stop_app_pool.vbs" "CRMAppPool"
set CRMDIR=C:\Program Files\Microsoft Dynamics CRM
xcopy "$(TargetPath)" "%CRMDIR%\Server\bin\assembly" /i /d /y
xcopy "$(TargetDir)$(TargetName).pdb" "%CRMDIR%\Server\bin\assembly" /i /d /y
cscript /nologo "$(ProjectDir)\iis_start_app_pool.vbs" "CRMAppPool"

 

The stop and start scripts: 

iis_stop_app_pool.vbs:

Option Explicit
Dim apool, strComputer, objWMIService, colItems, objItem
apool = WScript.Arguments.Item(0)
strComputer = "."
Set objWMIService = GetObject _
    ("winmgmts:{authenticationLevel=pktPrivacy}\\" _
        & strComputer & "\root\microsoftiisv2") 
Set colItems = objWMIService.ExecQuery _
    ("Select * From IIsApplicationPool Where Name = " & _
        "'W3SVC/AppPools/" & apool & "'")
 
For Each objItem in colItems
  Wscript.Echo "Stopping " & objItem.Name    
  objItem.Stop
Next

iis_start_app_pool.vbs:

Option Explicit
Dim apool, strComputer, objWMIService, colItems, objItem
apool = WScript.Arguments.Item(0)
strComputer = "."
Set objWMIService = GetObject _
    ("winmgmts:{authenticationLevel=pktPrivacy}\\" _
        & strComputer & "\root\microsoftiisv2") 
Set colItems = objWMIService.ExecQuery _
    ("Select * From IIsApplicationPool Where Name = " & _
        "'W3SVC/AppPools/" & apool & "'")
 
For Each objItem in colItems
    Wscript.Echo "Starting " & objItem.Name
    objItem.Start
Next

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by David Eison on Friday, February 27, 2009 1:09 AM
Permalink | Comments (0) | Post RSSRSS comment feed

SharePoint problems, copying from old content management systems

Different content management and versioning systems have different methods on how they track versions.  So when migrating from one system to another, you can run into issues.  We recently experienced this when moving some data from an old CVS tracking system to a new SharePoint system (though this also affects old Novell systems). 

 The quickest way to move a large number of file to SharePoint is, of course, through the Explorer window.  That way you don't have to manually make all your folders and everything else you might need.  However, this can lead to problems, such as these errors:

Error 0x8007011A: The mounted file system does not support extended attributes.  

or

Invalid MS-DOS function

Both of these indicate that the old CMS has some extended file attributes that SharePoint doesn't handle.  Stripping them is the only reliable way to allow SharePoint to manage these files.
You can let the web interface do this for you, but that means making all your own folders.  Not terribly quick when you're dealing with large moves.  There is a quick workaround that I used, and that is to move the files to a neutral location, zip them up, and then unzip them.  Archiving them that way actually strips those extended attributes, and Zip doesn't support them.  So now you have clean files you can copy over to SharePoint (sans any versioning from the old system).

Right now, we're also looking at building an app to automate this process, and possibly add some intelligence to it.

Also, does anyone know of any tools that can examine this kind of extended data?  That would make our lives a lot easier.

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Categories: SharePoint
Posted by Wayne Walton on Thursday, April 03, 2008 12:51 PM
Permalink | Comments (0) | Post RSSRSS comment feed

How to move SharePoint sites around

I found an incredibly useful article about deploying and migrating SharePoint content.

http://sharepointnutsandbolts.blogspot.com/2007/10/stsadm-export-content-deployment.html

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Categories: SharePoint
Posted by Eric Stoll on Monday, March 17, 2008 10:31 AM
Permalink | Comments (0) | Post RSSRSS comment feed