Except that when you attempt to deploy the second version of the code you get the message:
“This solution contains two assemblies with the same name, or the SharePoint server already has an assembly with the specified name.”
Huh? What’s going on here was my first reaction. After applying a little thought to it I realised that there was a solution package added and deployed to the SharePoint server that had same name as the one I was attempting to deploy. This solution package also contained assemblies of the exact same names as those that I was trying to deploy this time, in my case the C# version had been done first.
So knowing a little of what happens at packing and deployment time I opened up a file browser and looked in the bin\debug folder of the current project. Had the packaging worked I would have found a .wsp file and a setup.bat file, neither of these was present so the check that throws up this message must be run prior to packaging the .wsp file for our VB.NET version.
Luckily I had the setup.bat file from the C# version! So I just ran setup.bat /uninstall which will remove the solution package for which it was generated.
However, should you not have that file, it’s still pretty easy to get around this problem, it just requires a little stsadm fu!
Open up cmd and run these commands:
cd "\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"
stsadm -o enumsolutions
Now examine the XML output to see if you have a .wsp in that list that matches the name of the .wsp that will be created and deployed by VSeWSS for the project that you’re working on. If you do you’re in business!
stsadm -o retractsolution -name <Solution name> -url <virtual server url> -local
stsadm -o deletesolution -name <Solution name>
Note: do this with care! If the solution you remove is not on that you’ve developed then you might break other features in your SharePoint instance.