Hot answers tagged

7

When you have common/shared components, like the helper DLL you talk about, that get used across multiple solutions within you organization. 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 ...


4

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


4

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


3

It is present here C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5 When adding dll references click on Framework and scroll down, you should be able to see this:


3

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


3

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


3

I am pretty sure this video tutorial will gonna help you but make sure to do a IIS Reset after. http://www.youtube.com/watch?v=Y_QSoIMEzeU 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 :).


3

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.


2

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


2

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.


2

I've ended up openning Visual Studio Command Prompt. Navigating to the bin/Release folder of my Web Part and use the sn -T command on my DLL to get the Token!


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

I think, the problem is on line 1. There you specify an Inherits attribute together with the Codebehind attribute. You probably can't specify them togheter as specified here: http://msdn.microsoft.com/en-us/library/d19c0t4b(v=VS.90).aspx Also, if you specify the Inherits attribute, you have to specify the full qualified name of your type in line 1: <%@ ...


2

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. [System.Reflection.Assembly]::Load("rossri.NavigationControl, ...


2

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 :)


2

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


2

Running Build in Visual Studio will generate/create the assembly. Deploying it will simply register it with the SharePoint platform. Update: 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.


2

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


2

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 file system. Source 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 ...


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 use a .Net 3.5 assembly in a 4.0 project, but not the other way around.


2

Please Use NuGet Package Manager to add DLLs to your project


2

The assembly declaration seems wrong. Report here the Page directive, so we can see what's wrong. Anyway, it should resemble this: Inherits="AssemblyNameSpace.CustomPageClassName, AssemblyNameSpace,Version=1.0.0.0,..."


1

Instructions on how to deploy the SharePoint 2010 Client Object Model assemblies can be found in Client Object Model Distribution and Deployment Microsoft SharePoint Foundation 2010 installs Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\ISAPI for ...


1

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


1

This is your generated assembly, all you need to do is update the workflow and then use Update-SPSoution. SharePoint will know to use old assemblies for workflows that are still running on the old workflow after you update. Whenever you update a workflow as a solution, it will use the new version first, but keep the old version if there are any running.


1

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


1

Click on assembly and press F4 to load its properties in Visual Studio. Try changing the value of Copy Local to true. And check if your project uses the latest .NET version.


1

Your DLL must be declared as safe in the web.config of the Web app: <SafeControl Assembly="SPTestHnG.DataEntities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="SPTestHnG.DataEntities" TypeName="*" Safe="True" AllowRemoteDesigner="True" /> However, the best practice is to make it registered as part of a WSP deployment ...


1

After looking more carrefully at the code-behind, I noticed you inherit from LayoutsPageBase. However, your page is not an application page (inside _layouts), but a module (a file provisionned in a library). I've never seen a module .aspx page inheriting from it, but always from Microsoft.SharePoint.WebPartPages.WebPartPage. That may be the problem.



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