Hot answers tagged

7

In the Timer Job project, open the package designer. Click Advanced (bottome of the designer) Click Add, and choose Add Assembly from Project Output. Select Project A Repeat selecting the other project. All your assemblies will be in the Timer Job solution, and is the only one you need to deploy to SharePoint.


7

After you do all of the above, make sure you also completely remove the SharePoint Config database as well as delete your 14 hive.


7

"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?


4

As Ari says they are located in c:\windows\assembly, but if you browse that folder using Windows Explorer you will see a custom UI which shows the GAC. If you use PowerShell, a command prompt or other applications such as Total Commander (my favorite) you will see that c:\windows\assembly contains a set of other folders where the actual assemblies are ...


4

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 ...


3

if you work with powershell ensure that the thread that does the retract and remove is stopped and the deployment happens in a new thread. This is also relevant if you update FeatureReceivers from within a powershell script. You have to start the deployment/feature activation in a separate thread, otherwise the DLL is not released from GAC and remains the ...


3

One problem having "shared" references in your main WSP is that if it is shared and you retract the WSP you will make all other solutions fail. I tend to use a specific WSP that contains the shared references - this makes me avoid these kind of problems.


3

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.


3

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, ...


3

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 ...


2

I would create a different WSP with those dependent assemblies. You can version and deploy this WSP independently. Just be sure to not GAC deploy these assemblies from your solution WSP.


2

Try changing the Scope to Web and use <Receivers ListUrl="Lists/List">


2

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 ...


2

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 ...


2

Often this is due to the SPTimerV4 holding a cached reference to your solution .dll:s try do net stop SPTimerV4 net start SPTimerV4 in PowerShell or cmd when you have retracted your .wsp before reinstalling them


2

You can see the files in the Global Assembly Cache by browsing to %windir%\assembly\ (e.g. C:\Windows\assembly)


2

Yea, you'll need to do an iisreset or an app pool recycle for it to pick up the new dll in the gac.


2

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 ...


2

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 ...


2

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 ...


2

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 ...


1

Put it in the Web Application bin folder as well, sometimes it solves the problem or you might have to register it as a safe control in web.config, which should happen automatically i guess.


1

In line: <%@ 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 ...


1

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 ...


1

Check that assembly binding redirects from v.12 to v.14 are present in web.config. Thats what SharePoint uses to check what assembly to load.


1

You will have to deploy shared libraries to the gac if you are using Sharepoint objects... i had a simialar issue like this... Issue Refrence just have a look at my answer, it will explain why it must be installed in the gac. and how to add it to the Gac. their is also a seperate option. i have listed it their aswell


1

I get this exact problem myself. I can't work it out either, but I have noticed that it will only occur when I have certain source code files open and active in Visual Studio (in your case it would be a code file from the SecondLib project), and it would only occur when trying to do a package or deploy action. If you close the source files from SecondLib ...


1

I had the same problem. (Re-)Built successful but deployment to SharePoint and manually packaging (Visual Studio -> Pubish) failed. I solved the problem by switching "Copy-Local" to false in every project (about 15 Class Library projects and three SharePoint Projects). I think the problem is the linking between each project so Visual Studio can not resolve ...


1

If you got RDP access to the server, I'd do it this way. Open the C:\Windows\assembly folder Open the folder where your dll is located Copy the dll to the assembly folder Wait untill you can reset the webserver Do an iisreset /noforce or recycle the application pools via IIS Manager If you don't have (RDP) access to the server you could write a script ...


1

No, because it falls into ECM bucket of SharePoint 2010 server. The best way to answer similar question is to look into SharePoint Server 2010 SDK. If the assembly is documented under Library reference of SharePoint Foundation, it is available for it and vice versa. http://msdn.microsoft.com/en-us/library/ee559357.aspx



Only top voted, non community-wiki answers of a minimum length are eligible