Tag Info

Hot answers tagged

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

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.


6

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


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

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

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

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

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


2

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.


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

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

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


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

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


1

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


1

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


1

It looks like you can collect assemblies from the dev environment by PowerShell script. And then install them to the build server. You can modify this script to retrieve all needed assemblies.


1

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


1

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


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

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

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

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

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

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

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



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