Getting DLLs OUT of your non-managed code SharePoint solutions in Visual Studio 2010

Ever notice, that no matter what you package in Visual Studio 2010, even if it is a no-code solution? See the output of a build from a CustomAction below.

—— Build started: Project: Test.SharePoint.Features.MyCustomAction, Configuration: Debug Any CPU ——
  Test.SharePoint.Features.MyCustomAction -> c:\DevProjects\Test.SharePoint.Features.MyCustomAction\Test.SharePoint.Features.MyCustomAction\bin\Debug\Test.SharePoint.Features.MyCustomAction.dll
  Successfully created package at: c:\DevProjects\Test.SharePoint.Features.MyCustomAction\Test.SharePoint.Features.MyCustomAction\bin\Debug\Test.SharePoint.Features.MyCustomAction.wsp
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

There is a simple solution to this. Click on your project within the Solution Explorer in Visual Studio. And then below, or, wherever you have your Properties window, just change Include Assembly in Package to false. Then go ahead and re-package your solution. That was easy, eh?


Errors when writing applications for SharePoint 2010

So, you’ve opened Visual Studio 2010, say, for instance, a console application to start pecking away at writing some simple application via the API. Nothing major, maybe in fact you are just re-using code from 2007 you’ve written, but, you just want to play with the API, after you’ve finished drooling over the new UI. Great! So, you’ve written your code, you press F5 to debug run your program, and [insert failure sound from The Price is Right here] – you get an error. The error makes no sense? FileNotFoundException? You’re using the IW image from Microsoft. You know for a fact the site exists – its open in your browser on your other monitor?! And more importantly, you know this code words. You’ve muttered it out from your fingertips hundreds of times (or, have it pasted in through a code snippet – why re-invent the SPRequest object reference wheel?)


No need to worry – after you’ve no doubt put your hand through your nice looking but poorly made substitute-for-a-punching-bag IKEA Imon desk (its ok, they’re made that way so you don’t injure yourself! A few layers of wood putty will fix it up even better than before. Now your desk looks more “arty”. You’re hip now!), it is a simple fix. A console application by default in VS 2010 sets the platform target as x86. Not x64, not Any CPU, but x86. Which will NOT work with the 64-bit only SharePoint 2010. Set this back to Any CPU, or x64 if needed, and hit F5 again.


Now your cookin’ with gas! Simple, eh? A quick helpful hint – the Community Kit for SharePoint: Development Tools (CKS:DEV) project contains a project type called “SharePoint Console Application”, which sets all of this up for you, right off the bat.

%d bloggers like this: