This is a follow-up post to the Understanding folders and namespaces in Visual Studio 2010 SharePoint Solutions, Packages and Features (probably my longest blog post title, except this one…). In that post I discussed how folders and namespaces are handled in Visual Studio 2010 SharePoint projects. I will continue to show some details and tips on how you can affect the outcome of your project/packages.
Long feature folder names
As the previous post showed the features generated by Visual Studio ends up as a subfolder in the {SharePoint Root}\TEMPLATE\FEATURES folder. The feature folder will get the name as the concatenation of the project and the feature - which possibly can be quite long.
In the image above the project is called Wictor.Customer.Intranet.Services and the feature IntranetServicesWebParts. There is a good reason to have these auto generated names; it will avoid collisions of features. But if you are in control of the target farm you might consider having shorter names of your feature folders. This is easily done using Visual Studio; 
Open up the feature in the Feature Designer and select the Properties tool window. (Note you cannot right-click the feature(s) node in the Solution Explorer and select Properties - that will just give you the properties of the Visual Studio feature file.) If you take a look at the Deployment Path property you will see that it has a default value of:
$SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$
As you can see it uses the Visual Studio replaceable parameters to generate the feature folder name. Just edit this to something that fits your “style of coding”. It can be a combination of strings and replaceable parameters. For instance this:
Intranet_$SharePoint.Feature.FileNameWithoutExtension$
will generate a feature folder like this:
Just remember that it is a reason that the default value of the feature folder name is a combo of the project and feature names.
Project Assemblies
By default all SharePoint projects in Visual Studio generates an assembly which is registered in the GAC when deployed. This is done even if we don’t write a single line of compiled code. SharePoint allows you to do really neat stuff using only a declarative approach - such as adding content types, list templates, list instances etc. For these projects it is totally unnecessary to install an assembly in the GAC. Fortunately Visual Studio allows you to configure your project so no assembly is generated or rather included in the WSP package (an assembly will still be compiled and created but not deployed with the package).
If you have a fully declarative package and do not want to add an “empty” assembly to the GAC then you go to the Properties of the project (right-click the project node in the Solution Explorer for instance) and set the value of the Include Assembly In Package property to False.
Now when you package your solution no assembly will be created and you can deploy your solution using PowerShell without the -GACDeployment argument.
That’s all for today - have a great weekend!