Change the WSPBuilder DeploymentTarget to WebApplication
Deployment, Development, SharePoint, Tips & TricksBy default WSPBuilder builds solutions with the DeploymentTarget attribute set to GlobalAssemblyCache. All assemblies provisioned by the solution will be deployed to the Global Assembly Cache (GAC) of the target web server which might not always be desirable/doable. There are a couple of ways of how to change the DeploymentTarget to the bin directory of the target Web Application.
One way of changing the WSPBuilder’s default behavior is using the WSPBuilder.exe.config file. Changing the value of the DeploymentTarget settings would be applied globally instead on a per-project basis. Every WSP you build on your development machine using WSPBuilder would be built with the DeploymentTarget set to WebApplication. While such approach would do the job, it would take away the flexibility that WSPBuilder is supposed to provide.
Another way of overriding the default setting is using the command line version from either MSBuild or post-build actions. Using the –DeploymentTarget switch you could set the DeploymentTarget to WebApplication. You are very likely to use this approach if you’re already using the command line tool to override other parameters. If the DeploymentTarget is the only thing you want to change there is a better way which also allows you to use the WSPBuilder context menu in Visual Studio.
What you need to do is to modify the Output Path of your project. Go to Project Properties > Build and change Output path to 80\bin\.
![Changing the Output path of a project to 80\bin\](http://mastykarz.nl/blog/images/ChangetheWSPBuilderDeploymentTargettoWeb_9240/OutputPath.png "Changing the Output path of a project to 80\bin\")
The idea behind this solution is that WSPBuilder automatically deploys all assemblies from the 80\bin\ directory to the bin directory of the target Web Application. Of course you could manually copy the assembly to 80\bin\ it’s way better to have it done automatically just to be sure that the WSP always contains the latest version.
From now on each time you build your project and let WSPBuilder build the assembly, it will be flagged inside the WSP as an assembly to be deployed in the bin directory of the target Web Application.
December 30th, 2008 at 3:42 pm
Modifying the WSPBuilder.exe.config file does not have to be a global change. Individual copies of the config file can be maintained for an individual project. By placing a WSPBuilder.exe.config in the root of your Visual Studio project, it will override the global configuration file. I would think this would be preferable, as you can maintain the config file in your SCM, and also maintain all of the options that WSPBuilder affords on a project by project basis.
December 30th, 2008 at 4:37 pm
@liquidpooled: Doesn't the .exe.config have to be in the same directory as the exe? If that would work it would be cool indeed! Thanks for the tip
December 30th, 2008 at 5:12 pm
@Waldek – Just place a local copy of the config file (modified however you would like) in the root of your Visual Studio project. This is as of the latest release (http://www.codeplex.com/wspbuilder/Release/ProjectReleases.aspx?ReleaseId=16820) (Search for "local config").
December 30th, 2008 at 6:08 pm
@liquidpooled: Sweet! Must've missed this one. Thanks
June 1st, 2009 at 11:03 pm
Thanks for the post. Very useful.
October 30th, 2009 at 7:27 am
Thank you very much. That helped me!
November 22nd, 2009 at 7:25 pm
Thanks you very much. I had a small issue when I deployed my solution. I have deployed my solution to one webapplication.
But other applications also showing this feature when I check in the site collection features page. When I activate the feature ..I could see that respective master page in the master page dropdown..and when select it and go to home page ..saying unexpected error. It shouldn\'t show to all applications since I deployed to particular application. Did I do any mistake in my class or?? Thanks in advance.
November 22nd, 2009 at 9:22 pm
@venki: Unfortunately for you, that's the way SharePoint works. After deploying the Solution, the Feature is being copied to the 12 SharePoint directory. From there it is visible to every Web Application/Site Collection/Site in the whole Farm and there is nothing you can do about it.