A: 

On our test and debugging system we have the problem that our web application is not reachable under http://localhost, which is the normal path VSeWSS uses to deploy a solution.

To solve this problem we've changed the URL within the "Start Action" option from http://localhost to http://our machine's name. You find this setting under "Project"-Menu >> "Properties" >> "Debug"-Tab >> "Start Action" settings.

In or case we still deploy the solution from and to the same machine, but under a different name than http://localhost, so this might also solve your problem.

Flo
A: 
  • put your MySolution.WSP in a common share
  • remote in
  • run stsadm like this

stsadm -o addsolution -filename ..\MyPath\MySolution.wsp

stsadm -o deploysolution -name MySolution.wsp -url MyUrl -immediate -allowGacDeployment

thanks I will try this out
Anders
+2  A: 

Your screenshot suggests that you're using Visual Studio Extensions for Windows SharePoint Services. VSeWSS as of now does not support deployment to a remote machine.

Sorry we weren't able to support remote development. There are a few options of course but all of them need Visual Studio 2008 and Windows SharePoint Services 3.0 on the same machine.

That is what Paul Andrew said in first reply of this thread.

Only tool that I know of, which does this, is SPDeploy. Though I haven't tried it.

thanks for the link
Anders
A: 

I am assuming that you are wanting to do this as part of your development process, i.e. quickly update the web part after you've made some changes and compiled it.

If not then ignore the rest of this!

  • The first time only - Deploy to the BIN directory manually using STSADM/tool of your choice
  • Ensure when you build that the Assembly Version doesn't change, but the File Version does
  • Create a batch file to run on the PostBuild step to copy your web part dll over to //YOURMOSSSERVER/c$/inetpub/wwwroot/wss/80site/bin , or wherever they are in your setup.

In this way each time you build the web part dll will be copied over and automagically picked up by SharePoint on the next page load.

Obviously you wouldn't want to do this on a test/qa/production server.

Ryan