This is because it is not deployed by your solution, only referenced!
In Visual Studio, double click the Package file and choose the "Advanced" tab.
Then on that tab add a reference to the file from where nuget downloads it in your project folder. This way it will be deployed to GAC on installation of your wsp
I recently had some more time to review this old issue and try to give an actual answer to my question.
After some more testing, I was able to determine that (when used on a SharePoint 2013 farm):
Using Costura.Fody to embed libraries works when deploying libs to the BIN folder and fails if the lib are deployed to the GAC.
Module Initializer works for ...
My recommendation would be that you shouldn't.
You should start from scratch again and develop your Web-Application to be deployed below the _layouts folder in SharePoint using a WSP package and all of your code should be in code behind which is compiled into a dll deployed to the GAC.
You can technically get your solution to work, but it's a hack, that ...
So, when you reference a dll created in a different project and reference it in your SP project, you need to add it to the Package.
To make Visual Studio adding 3rd party assembly or even your own assembly from other project in solution to GAC please do next:
Open Package.package from Package folder in SharePoint project.
Click Advanced in bottom area.
I am pretty sure this video tutorial will gonna help you but make sure to do a IIS Reset after.
Its quiet simple, all you need to do is, drag your dll into Assembly folder in Windows which is located mostly in drive where you installed Operating System.
Hope it helps :).
Localization of feature.xml differs from localizing something else. As by Microsoft's reference, you have to create a special Feature resource file (which will be stored along with the feature) in order to do that:
How to: Localize a feature (MSDN)
Based on my experience, if you deploy your resources into "Resources" mapped folder (in 14 hive), they will ...
All the information in the .dwp (and .webpart) files including the assembly version is only a blueprint for which web part and corresponding properties to load when you select this web part from the WebPart gallary, SharePoints WebPartManager will then store these settings (possibly updated by user) in the content database. Each time the webpart page is ...
You need to add the Cassia DLL to the GAC or assembly folder. You can do it by using gacutil command from visual studio command prompt.
gacutil /i C:\mydll.dll
Replace the path and name of dll with yours in above.
Go to Package.package in your project and double-click it.
Click the "Advanced" tab
Click "Add" and "Add Existing Assembly.."
Click the "triple-dots (...)"
Navigate to your project folder and then to the .dll in the bin-folder and click "Open"
That should be it
The assembly declaration seems wrong. Report here the Page directive, so we can see what's wrong.
Anyway, it should resemble this:
The method I use is to merge all assemblies into one using ILMerge as part of the build, before packaging
This make its bulletproof as then its impossible for someone to somehow remove dependant assemblies.
Here is a link to a page that describes the process for the out of the box SharePoint webparts. If you want to include your own webpart, you need to add a reference to your assembly in powershell. The following line adds a reference to one of my custom webparts into powershell.
Your approach is quite correct. Have a separate wsp and deploy the common dlls to GAC.
Now for your questions :
For development of other solutions in Visual Studio which need to refer these dlls,
Just add assembly references as you normally do, choose browse option and select the required dlls. I would recommend navigating to c:\windows\assembly\gac_msil\...
Given what the Cassia DLL is trying to do, it should be in the GAC so that it runs with Full Trust. Even then you may hit permissions issues but those should manifest themselves differently once you get past the initial loading of the DLL.
The source code is readily available for the Enterprise Library so if you are going to use it, you should rebuild it using one of your keys so that it can be put in the GAC and then easily reused by other applications. Once that is signed, you should do the same with your web parts.
However, if you wish to DLLs without strong names then you will need to ...
This isn't a SP security issue, it's a file system security issue.
Make sure the identity running this code has permissions to read the
Make sure your C++ library has sufficient file permissions so that SharePoint can access it. You can match permissions with your development environment.
Other then that all I can think of is ...
Just drag and drop the ajaxcontroltoolkit into the assembly. You can add the ajaxcontrolltoolkit dll also to your project through references. Do an iisreset as you made an ammendment to the GAC(assembly).
Now your project (webpart or anything that is using the ajax dll) has reference to the ajax dll.
hope it helps :)
This isn't my forte but I ran across the note below on this MSDN posting; perhaps that will help.
If you wanted a job to run on all servers, including application
servers, your class should derive from SPServiceJobDefinition. Pass
the timer service (SPFarm.Local.TimerService) as the SPService
parameter of the SPServiceJobDefinition(String, SPService)...
Running Build in Visual Studio will generate/create the assembly. Deploying it will simply register it with the SharePoint platform.
As David added, the "Deploy" command in Visual Studio does also trigger the build event before it is deployed to SharePoint. The act of deployment within SharePoint though, simply registers it with SharePoint.
Often this is due to the SPTimerV4 holding a cached reference to your solution .dll:s
net stop SPTimerV4
net start SPTimerV4
in PowerShell or cmd when you have retracted your .wsp before reinstalling them
changing out the project’s strong key assembly worked in this particular case. If you haven’t had to change this before, it is under the properties of the project -> Signing. Under ‘Choose a strong name key file’, select New. The password is optional.
But it will allow you to access that ...
Whereas FeatureAdmin can help you with missing feature dependencies, you may need to recurse to other means to properly remove those unwanted event receiver references, that can be at many levels (content type, list, etc.)
I have used the below script in a similar scenario.
$receiverName = "ECDC.DMS.EventReceiver, Version=22.214.171.124, Culture=neutral, ...
The classes in the System.Collections.Generic namespace is in System.dll and mscorlib.dll, so you won't find a DLL named System.Collections.Generic.dll.
Generics were introduced in .NET 2.0, so because SP 2010 requires .NET 3.5 to run, the namespace should be present in those DLLs. Make sure you're targeting the right framework in the project's build ...
The first step would be to verify that the SharePoint Timer service is running properly on all servers in the farm. Beyond that, you would need to look at Central Admin and see if the deployment of the solution generated unusual errors for the other servers.
If that all looks good then you probably need to understand the nature of the update. Did the ...