Tag Info

For Features
SharePoint Features can be scoped to the Farm, Web Application, Site Collection, and Web Site level depending on the purpose of the feature. The Feature scope is determined by the setting of the Scope attribute in the Feature element defined in the feature.xml file.
A sample Feature element tag is given below:
<Feature ...

In our working project, we have "Common" dlls too. And finally, we came to a "container"-project concept.
So, if I understand correctly, you have 3 wsp's but only for development reasons. It is much better for development to have many little projects, than one huge monster, isn't it? :) But for installation, better to use all-in-one approach.
And here is ...

I'd avoid branching as it will get very difficult to manage when multiple webparts are under different parts of development. Been there - a messy code handed to me and had to figure out better way to maintain.
This kind of issues crop up due to "type-based" project structure, where all webparts are under "WebParts" project, all features are under ...

Can you check that ou have enabled and configured the user code service on your farm and started it?
Look for user code service in service applications and create one if it is not there.
Then go to
Central Administration > System Settings > Manage Services on Server > check that “Microsoft SharePoint Foundation Sandboxed Code Service” service is running

SharePoint solution packages consist of a .WSP file that you can create using Visual Studio (or manually if you so wish).
Before deploying to a production environment, I recommend you take a look through Deploy solution packages (SharePoint Server 2010).
Basically you need to add your solution to the solution database of a SharePoint Server farm using the ...

I had the same problem today. I compared the project files with an older version. In my case the Package directory (with the files Package.package and Package.Template.xml) was missing.
After copying this directory back from the older version of the project and modifying the csproj file to include the references to the package directory, the error solved ...

This can occur when an installed feature is renamed. Either reverse the rename or uninstall the feature.
PowerShell's Uninstall-SPFeature <Guid> -force will not work. You should use stsadm -o uninstallfeature -id <Guid> -force instead.

SharePoint can absolutely do this for you. You should take a look at the MS documentation on the Portal capability: http://sharepoint.microsoft.com/product/capabilities/portals/Pages/default.aspx.
I've seen a lot of talk within enterprise sized organizations about platform commonality and streamlining the system management end. When you've got a bunch of ...

Visual Studio deploys to the server it's installed on, and as a best practice it shouldn't be installed on any production server. During the deployment process, the applicable bits for the solution will automatically be "deployed" to any server in the environment with the Foundation Web Application role. For deployment to production, the correct process ...

There are a couple of options here:
Use STSADM -o backup/restore
Use STSADM -o export/import
Use Content Deployment, perhaps with the SharePoint Content Deployment Wizard (a tool I wrote)
When you use backup/restore, you get everything - including recycle bin content, running workflows, alerts etc etc. This may or may not be what you want. Such ...

We can either manually do it through central admin or by using powershell commands.
I would prefer doing this through powershell
To uninstall and remove Farm solutions use the Uninstall-SPSolution and Remove-SPSolution cmdlets (Use -WebApplication attribute if the solution has webapplication-scoped resources):
Uninstall-SPSolution –Identity ...

When you have common/shared components, like the helper DLL you talk about, that get used acros multiple solutions within you ogansisation. My recommendation is to package these up as a 'framework solution' that is deployed to the servers indendently of the 'feature based solutions'.
This way you 'feature solutions' are developed in the knowledge that ...

As the documentation states, when you add new artifacts to a solution you need to reinstall it. Really nothing new here, except for support for solution dependencies (and this is really only half implemented, since you can delete solutions that other solutions depend upon without getting any warning)
Feature upgrade is an entirely different matter. No ...

Also check that you dont have a version of the assembly in the BIN folder of your IIS website.
Note that it is considered a best practice to package your web part in a solution (WSP) and deploy it this way.
Also as noted in SO answer, make sure that you are hitting the right WFE. If you have several web frontend servers, you must manually update all GAC's ...

To deploy a .wsp farm solution you need to be a local administrator on the server:
Adding a solution package
Before you can deploy a solution package, you must add it to the solution database of a SharePoint Server farm.
Important: You must be a member of the Administrators group on any computer on which you run Windows PowerShell.
To ...

Elements by Scope helps you understand what elements are allowed for each scope. That also means that solutions can be developed and SharePoint architecture allows them to be deployed at any of the scope documented.
Most solutions use FEATURES that are targeted at web or site collection level and when an element is allowed at both web and site level, it ...

You need to move the list Url to your module definition:
<Module Name="Style Library" Url="Style Library" RootWebOnly="true">
for GhostableInLibrary to work properly. You should of course then remove it from the File Url, since it is now defined on module level.
If you have no Url in the Module tag you can only use type="Ghostable" on your File ...

At the beginning of your FeatureActivated method, put this line of code :
System.Diagnostics.Debugger.Break();
Then, try to activate the feature. This will popup an "exception" window that let you to attach the debugger of your choice.
After attaching, your code will be pause at this line, and you will be able to walk into your code to find the issue.
...

OMG Noooooooooooooooooooooooooooooooooooooooooooooooooooooooo!
Sorry to be over dramatic, but you will end up in a world of pain if you even attempt to do this. Use SharePoint WSP solutions to deploy to multiple WFEs. This process is well documented and very simple, especially if you use the excellent wspbuilder at CodePlex.
If you want some guidelines on ...

Focus on packaging up EVERYTHING as Features, Site Definitions, DLLs, etc in a WSP. You will use this portable installer package to deploy to other environments (staging, production, etc).
There will most likely be some extra work involved in "solutionising" any custom funcionality that was created with SharePoint Designer. You will need to get familiar ...

The Visual Studio 'Deploy' command actually invokes all the deployment steps in the current project deployment configuration. If you go and check by default it performs many seperate tasks under the coverall of 'Deploy'. That's under the SharePoint tab of the project properties window.
The 'Deploy' function also does conflict resolution such as deleting the ...

I suggest you should deal with the problem after going through httphandler development and its deployment in IIS 7 and ASP.NET 3.5. Here is a good link : http://msdn.microsoft.com/en-us/library/bb398986(v=VS.90).aspx
(See various walk-through and consider asynchronous handlers as you deal in asynchronous way)
If you think you know it all, Please ensure :
...

I strongly recommend that each dev has it's own installation. It could be a Virtual machine (single machine with AD, SQL and SharePoint). It looks like your company is not shy on resources so it might be possible for you.
2 people (or more!) on the same box will lead to frequent delays as you deploy/recycle, hook the debugger, or if you want to test a ...

Last year, Microsoft launched a dedicated site for SharePoint user adoption which can be a good place for you to start with.
With addition to the above, I believe your prime concern should be planning a collaboration roadmap on SharePoint.
This will essentially include high level areas like
Current use of Office 2010 products within your organization and ...

I'm pretty sure that if your assemblies contain feature receivers then they need to be installed into the GAC.
There is a post about it here, but in my opinion it doesn't give a good explanation why.
My theory is that when you attach a feature receiver to a feature, the assembly needs to be globally available, since FeatureInstalled/Activated etc can be ...