"Assembly Deployment Target" property is disabled at a sandboxed solution, you're correct. But it's also disabled when developing a farm solution when the property "Include Assembly in Package" in the same properties window is set to False.
Can you verify this setting?
As the name suggests, Assembly deployment Target; specifies where the assembly i.e. dll of the SharePoint will be deployed to. So, in case of WebApplication deployment target, the assembly will be loaded in the bin folder represented by the IIS site. For example, the deployment is done to port 80 site. Then the path may look like this C:\inetpub\wwwroot\wss\...
I can't find a resource on this atm, but the main differences are:
if your solutions contains dll's it will ask to deploy them to the gac. I've personally not deployed them to a specific web app's bin folder yet.
if your solution contains webparts or other resources that require modifying the web app's web.config file, it will ask you what web application ...
I typically advise to place "shared" libraries into a dedicated WSP and keep it out project or function specific WSPs. If a specific WSP is retracted, the "shared" library will still be available. Examples of "shared" libraries are: log4net, Enterprise Library, your own shared libraries, ...
If you have a farm with multiple servers, you'll need to update your dll's in all of the servers.
but if you have only one server, you can drag your dll to the gac folder or use the GacUtil.
In any case I would suggest you to deploy your dll using a WSP solution which will copy your dll to all of the servers on your farm.
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\...
Paul Beck has a good blog post about this: http://blog.sharepointsite.co.uk/2010/07/deploying-to-gac-vs-bin-folder-in-sp.html
My general rule is: Deploy my custom code to the GAC except if it's not trusted i.e. 3rd party code or there is a business reason/policy not to. It makes dev easier but is not ideal in that best practice decitates that you should ...
When Fusion (the system behind .net that controls assembly binding) looks for an Assembly it will always look in the GAC first.
Whats probably happening here is :-
You deploy your timer job assembly v1
The Timer service loads the assembly v1
You deploy your new timer assembly to the GAC (v2)
The Timer service already has V2 'bound' so it will not load ...
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
The issue was resolved by adding a strong-name assembly reference in the ascx file pointing to the code-behind assembly.
If your ascx file's assembly references do not include strong-name, like this:
<%@ Control Language="C#" AutoEventWireup="true"
CodeBehind="SomeFile.ascx.cs" Inherits="SomeNameSpace.SomeClass" %>
Try adding a full assembly ...
For SharePoint 2007 deployment, I personally use WSP builder, works great as far as you use it properly.
However back in day,s I used to add a project output to solution and then generate CAB files, then convert CAB file into WSP by changing file's extension and use STSADM command for deployment.
In newer version of SharePoint (2010, 2013) & Visual ...
what i am thinking, if you are doing some development with SharePoint Online / Office 365, then you can see the version 16 for client dll. Office 365 always ahead of race, currently if you see the version for office 365 it is 16.
So that make sense, if their some development or development tool installed for office 365.
check this one http://blog.aptillon....
The error is really not self-explanatory, however the only problem is that you don’t have enough permissions on the Site or Web. Even if you are a farm admin and local admin on the server, some SharePoint PowerShell Commands will not allow you to run at the Site or Web level.
Easiest way to fix it, since you already have access to the server, give yourself ...
We had this issue in recent past, for us this dll stuck in timer service cache. I would do the following things:
Restart the SharePoint timer and Admin service on all server in the farm
Reset IIS on all servers
I solved the problem. It seems there is no need for me to reset either IIS or SPAdminV4 during the deployment. Removing all references to this from my PowerShell script solved the issue.
I should also note that waiting 5 seconds after resetting SPAdminV4 before activating the feature also avoided the error.
When you deploy a web part in SharePoint, you provide it a type and assembly in an xml file that registers the web part in SharePoint.
Look at this: Web Part Deployment
In the .webpart file you'll see the line
<type name="ExecutionModels.Sandboxed.AggregateView.AggregateView, $SharePoint.Project.AssemblyFullName$" />
If you're rebuilding the ...
Normally all the artifacts should be part of the WSP itself. You should be simply Adding the solution and then deploying it. No need to manually adding the dlls to GAC and adding safe control entries.
You should get in contact with the company from whom you purchased the web part. They can provide you better guidance. However, I remember the days when I ...
add this just above your public class file!
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Impersonate = true)]
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, ObjectModel = true)]
then let wspbuilder do the rest for you as it will build the xml file for you within the manifest file!
You can try Alexander's PowerShell link but if you want something really easy and quick which will enable you to get assembly you want from gac then you can try this,
Click start and then on "Run",
Put this command in it,
%windir%\assembly\GAC_MSIL // you move back a directory it will show you gac as folders which you can copy and that.
If your ...
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 ...
Just execute the next bit running as local administrator.
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
Make sure the dll you downloaded matches your development machine as if both are for x86 processors or if they are for 64 bit, if that's fine then just drag and drop DDayICal.dll to Gac and do a IISReset, and reference it to your project as well, it should work straight away without giving an error for strong file name, however you should check these links ...
<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="act" %>
put more information about assembly sth like this:
<%@ Register Assembly="AjaxControlToolkit, Version=x.x.x.x, Culture=neutral, PublicKeyToken=xxxxxxxxx" Namespace="AjaxControlToolkit" TagPrefix="act" %>
Version and public key token you can ...
I've explained some possible approch in my anwser of the question Best practices for creating a shared code library for SharePoint projects.
Basically, what I'm suggesting is to build a wsp file with the required shared libraries. Then create a feature, just to say the libraries has been deployed.
In you project, you can simply reference your dll, set the ...