STADM always reverts to the Program Files (x86) Path

Sep 23, 2008 at 7:13 PM
I am developing on a x64 bit configuration (SharePoint, SQL Server, VS.NET, etc).  I am using the latest release, 1.3 of STSDev.

When attempting to BuildInstall or BuildDeploy a solution, I get an error stating that stsadm.exe cannot be found.  In the output window, it is looking in the "C:\Program Files (x86)\..." path.

I've tried several things to get it to work (even downloaded the source and built it for x64), but nothing seems to work.  I think the Microsoft.SharePoint.target file is getting cached somehow.

Here is some of what I tried to do in the Microsoft.SharePoint.target file:

  • I updated anything that uses $(ProgramFiles)\Common Files to use the common program files variable (as another poster suggests)
  • I hard coded  the full path (removed variables)
  • I added a comment above the line that executes stsadm.exe and it appears and that text was not written to the output window.  I then commented out the lines that actually execute stsadm.exe and it still wrote the attempt to the output window.  This is what leads me to believe it is getting cached.
How can I work around this?  Any help would be greatly appreciated.

Cheers,

Mark

Sep 29, 2008 at 7:34 AM
I seem to have the same problem. I have sharepoint installed on a VM. I mapped the C drive on the VM as Y and eventhough I set STSAD to the Y drive STSDEV still seems to go to my C drive
Oct 24, 2008 at 9:17 AM
Edited Oct 24, 2008 at 9:21 AM
If you're making these modifications to the generated Microsoft.Sharepoint.Target in your own solution, remember to restart Visual Studio before you execute a build (don't know why).

Regards,
Robin
Jan 28, 2009 at 5:07 AM
At least some of the problem stems from a hardcoded reference to a particular path for the .NET Framework which doesn't account for the 64-bit version. This occurs when the Build engine object is created, and causes the version of MSBuild to be the 32-bit version, which in turn is smart enough to use the (x86) variation of the Program Files system folder, which breaks a bunch of things in 64-bit land, such as the path to stsadm.exe.
I haven't resolved the problem, but JTHAKE is identified in the code as the guy who made the change, so maybe we should bug him to get this resolved :) My VM is shutdown, but I will find the file, and document this tomorrow.

Craig
Feb 17, 2012 at 5:11 PM
Edited Feb 17, 2012 at 5:12 PM

I just recently ran into the same problem.  I had to hard code in "C:\Program Files\" instead of using the "$(ProgramFiles)" variable.  Once I did that, and closed and reopened VS, it worked for me.

edit:  I'm using stsdev 1.4