GOOD ON YA!!!
– You’ve just saved yourself loads of pain.
(I think this itself deserves a good post, my colleagues are currently building the next version of VSeWSS at the time of this post, may God be with them!)
GOOD ON YA!!! (X2)
– SharePoint development have just become less painful🙂
Here are a few tips and tricks I learnt along the way and from my experienced and knowledgeable colleagues from Intergen.
#1. Why STSDEV is ignoring changes made in targets file?
Close your solution in Visual Studio and reopen it, and yes we’ll have to repeat this each time we make a change to the targets file. I know it’s a pain in the bum.
What is up with this close/reopen business and how to fix it? When you find out, please do let me know🙂
#2. Why is my solution deployed globally?
After a project is created with STSDEV, the default solution deployment command under DebugDeploy Target in targets file is;
To change your deployment to a site collection;
where $(TargetUrl) is defined as a property between <PropertyGroup> tags at the beginning of the targets file;
#3. “This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application.”
This is a tricky one. The error message is very generic and can mean many things… To resolve it, you need to flick between the targets file and the SolutionConfig.xml file, make changes and trying deploying it.
Remember, each time you make a change to the targets file, close your solution and reopen it for it to take effect in the build.
If you’ve written any custom code in the project, like event receivers, and you need deploy this assembly to GAC. You’ll have to make each and very single following points are addressed.
(Depend on the option combinations you chose when you created the solution with STSDEV, none / some / all of these should have been done for you.)
a. The assembly is signed with a key file. (Project -> properties)
b. In SolutionConfig.xml, allow GAC deployment and safe control.
c. In SolutionConfig.xml, specify the safe control.
You can get the assembly name by opening up the dll in reflector after signing it with a key and compiled the project.
d. In targets file, under BuildDeploy target, solution deploy command allows GAC deployment.
e. If solution is to deploy to a site collection, specify the URL in the deploy command as well, so it knows which web config to place the safe control in. (See the above code snippet.)
f. If you are intending to deploy to all Site Collections in this Web Application, make sure you specify so by having a -allcontenturl switch in the command.
Failing all above, keep Live.com ‘in😉
#4. “This solution contains resources scoped for a Web application and must be retracted from one or more Web applications.”
If you have successfully deployed your wsp solution to a specific site collection following the steps in #2 and 3, then you might come across this message when you try to build the project in “DebugRetract” or “DebugDelete” build targets.
If you take a look at the output windows it fails at line:
This happens because we haven’t specified the site collection URL that we had deployed the wsp solution to. So, if we change the line to.
Remember to close and reopen your solution for this change to take effect, then build it. You should see the problem go away.
#5. Can’t Debug I hear you say?
There are a couple of things you need to do here,
One is, allows a pdb file to be generated each time you compile the project. in Visual Studio 2008, right click on the project -> Properties -> Build -> Advanced… -> Debug Info -> full
So repeat this for all the concerned Configuration target. I recommend do it for “DebugRefreshAssemblyInGac, DebugBuild, DebugDeploy, and DebugRedeploy”. Not sure about “DebugUpgrade” never used it before.
Two is adding the pdb files to the correct GAC location. First you’ll need to find out where in GAC you’ll want to copy the pdb files into.
Start -> Run and type in “C:\windows\assembly\GAC_MSIL” as it can’t be opened through a file explorer.
Follow your nose and you should find the directory where the bit was deployed to, copy out the path from Address bar, this is the folder you want to deploy your pdb file to.
So in your target file, you need add two lines to your “DebugDeploy” target and “DebugRefreshAssemblyInGac” target like to following;
Remember to close and reopen your solution each time you change the target file.
Make sure the timestamp for these two files are identical, or your code is likely to be out of sync with the pdb.
#6. Have a post build script depending on your build targets?
In your target file, add a new property inside <PropertyGroup> tag.
And use this as a command in any targets in your target file, like so;
– I hear you ask, why wouldn’t you just use Build Event from project properties?
Because STSDEV introduces a handful of build targets (10 of them) and sometimes it’s useful to have control over which targets you want to have a post build script while not others. Also, we can run different post build scripts for different build targets leveraging this approach, just define different scripts as properties inside <PropertyGroup> tag then just invoke the appropriate ones from different build targets.
– Note, in theory we should be able to put anything we have in a post build script in the target file. After all, the targets file is just a script file in an XML format. But to me, I want to be able to share my build script around with other developers or from project to project. By extracting some of the common tasks out to a build script I’m protecting myself against having to relying on STSDEV. After all, STSDEV is just one of the great tools out there. That’s just my opinion, your mileage may vary.
#7. Have multiple projects under one solution?
When you first create a project with STSDEV and call it Play, It will lay out its folder structure like so;
When you create more than one projects and shift them to a sub directory to where the solution file resides, like so;
Then you compile your project, you’ll see this error;
and this in your Output Window;
This happens because, STSDEV uses solution directory to reference its deployment files and these files are per-project based. When we moved the project related files and folders else where, we’ll need to reference them by project directory.
All you need to do is to change the follow line in your <PropertyGroup> in your targets file.
Close and reopen the solution then try building the project again!
#8: “error : Cannot create INF file: setup.inf”
This happens because STSDEV will try to create/write to files called setup.inf and setup.rpt. The chances are you have these two files under source control so they are locked.
setup.inf, setup.rpt in project directory, along with manifest.xml and SolutionPackage.ddf in DeploymentFiles folder will get regenerated and written to each time you build your project. So don’t have them under source control.
#9: “Where are my web stuff?”
Enlightened by a colleague of mine – Matt Smith – a SharePoint Evangelist. When you create a project with STSDEV, the project is a C# library type.
When we add New Items, there isn’t a great of items are available to us. Especially when we develop SharePoint solutions, ASP.NET artifacts like ascx User Controls, aspx pages etc…
For us to be able to add web stuff to the project, Visual Studio needs to see the project we are adding stuff to – is a Web Application Project. To achieve this, add the following line of xml to the first <PropertyGroup> node of your .csproj file.
Reload the project and we see the project icon has become it of a Web Application Project;
and we can add all the web stuff to our project now;
There you go, the joys and pains for working with STSDEV.