I am trying add new function inside my SharePoint and I created HTML code and it will call .dll file where I download it. However, when I run project standalone outside SharePoint it works. However, inside SharePoint code (HTML) when I add assembly to my .dll , it shows not found.
I tried adding it in SafeControl in web.config bug still same issue.
I place .dll in all places where other SharePoint .dll are there but still the same problem.
I am not sure if I understood what you trying to accomplish but I suspect you are using some SharePoint on-prem and you deploy some kind of solution (webpart or other) to a site were you want to use an external dll. If that is the case you need to create some kind of empty sharepoint farm project (or use one of the existing farm solutions) and add an external dll to it so it will be deployed to GAC. When an dll is in Global Assembly Cache then we may use it in all places in SharePoint.
Here I found some blog post how to add a external dll to GAC
I hope this will be of any help
When the project is running inside the SP server, it's different from when it's starting outside the farm. You need to ensure the dll has been copied to gac, or the server cannot find it.
If you're developing a custom WCF in SP on-premise, you may take a reference of below demo:
Custom WCF
More reference:
https://blog.mastykarz.nl/including-additional-assemblies-wsp-visual-studio-sharepoint-development-tools/
BR
Related
I have multiple Excel Web Parts in my SharePoint 2010 site. Each web part is connected to an Excel work book which is generated automatically by a scheduled task on a separate server. Given this, is there a way to automatically map a newly generated excel file to an existing excel web part instead of manually updating them?
I saw a tutorial but it uses the SharePoint dll and other dlls which are found from the SharePoint server itself and as far as I know, I can only execute these items if I have SharePoint installed locally. Is there any way to make it work without having to install SharePoint locally? By the way I was referring to this tutorial from MSDN.
Edit
I was able to create web parts programmatically using SharePoint.Client.WebParts but I'm having problems creating Excel Web Access Web Parts.
I was able to make it work by using the same concept found in this page.
All that I needed to do was properly escape quotation marks from the exported web part file in order to map the correct file.
I have converted a large project, currently in VS 2012 from a Web Site project to a Web Application project.
I have added the namespace to all of my .cs files.
I have ran the "Convert to web application" on the project and it has generated all of the needed files. (So I do have the designer files created as part of this upgrade)
When I compile, it errors off on all of the references in my C# code behind file for all of the UI Controls. The error indicates that the control does not exist. The controls are there, and they are present in the designer files.
I have cleaned my solution and no matter what I do I get this error.
Any ideas / suggestions of things to try? Have I missed something in the conversion to a Web Application?
Fixed My Issue.. It was the inherits statement in the ASPX. I had to include the namespace along with that... Problem solved... so, the syntax is inherits="namespace.formname"
I'm new to SharePoint and trying to get my head around this. I have a simple Web Part project. I also have a custom Data layer project that uses the Microsoft Enterprise Library for data access. In the Web Part project, I am adding a reference to the Data layer project's assembly. I specified in the Package of the Web Part project that I want my Data layer's assembly to be deployed. I can verify this works by using standard ADO.NET classes and not the custom MS library. If I deploy to the SharePoint server (which I have 100% access to) using the Enterprise Library, I get the error message:
"Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Data"
What steps do I need to take to ensure this project and all future projects on the server can easily gain access to the Enterprise Library for data access?
Thanks!
You did everything correct until a certain point: Deployment.
When deploying external DLLs, which shall also be put into the GAC or somewhere else, you need to package them with the WSP aswell. This has become very easy with Visual Studio 2010:
Open your Package
Click on "Advanced" (on the bottom)
Add your external DLL and maybe even SafeControls for the web.config
I am creating a SharePoint solution project that will install the Telerik dll files into the GAC and write the appropriate lines into the webconfig upon feature activation. My question is, is there a way to get the product key token, version, and culture info of a dll programatically. I have used the System.Reflection.Assembly.GetExecutingAssembly() before to get the embedded resources, such as a javascript file, and add it to the appropriate folder. Would this be the same way to get the dll file, and if so what would I do to get the assembly info of an embedded assembly? Thanks for any direction.
See this related question.
Out of curiosity, where in your web.config are you adding references to Telerik DLLs? I recently did a project that uses the Telerik Silverlight controls. While I had to configure the web.config to support the .Net 3.5 framework, I did not have to add anything specifically for the Telerik DLLs as their controls were all wrapped within my custom Web Parts.
According to MSDN, for deploying custom web service, we need to create *wsdl.aspx and *disco.aspx files, and put them with .asmx together under _vti_bin folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\isapi). And put the dll under bin folder of the root of sharepoint virtual directory. It works correctly for me.
However, i also found that if i put .asmx file under the root virtual directory without creating those *wsdl.aspx and *disco.aspx files. It can work as well and much easier than the above way. So i'm wondering what's the potential issues in this way?
Without the WSDL and DISCO files, folks' web service clients/consumers may have a hard time "discovering" your service's contract. If that's not a concern for you, don't worry about it.
I have created several web services in SharePoint 2007 that were simply deployed as http://.../_layouts/mySubFolder/service.asmx. It works! For SharePoint it does not matter whether the presentation layer is HTML or XML for a web service (in both cases security must be applied, can be addressed both as http://server/_layouts/mySubFolder/service.asmx and http://server/sites/subsite/_layouts/mySubFolder/service.asmx
Things that are wrong thing about it
the word "layouts" implies "something to do with how it looks like".. which is not the case when we speak about web services
when migrating to SPS2010 where WCF services come into play, it will be different. However, I have not yet played with SPS2010 and do not yet know, how different. (Somehting about it here - http://blog.mastykarz.nl/wcf-sharepoint-context/)
Quite an old post but just thought i'd add to this as I don't believe the responses to date give the relevant detail on why SharePoint is setup this way.
The reason why you deploy webservices to ISAPI\vti_bin for SharePoint is because there are specific modifications made for requests to this folder to allow SharePoint to build an accurate discovery and WSDL file for the service based on the current virtual path of the service, not the path in the IIS site.
More specifically wsdisco.aspx and wswsdl.aspx handle requests to this virtual directory and will call the relevant disco.aspx and wsdl.aspx to generate the discovery xml or wsdl xml correctly based on the current SharePoint url.
If you add a service reference to your project for http://sharepointsite.com/sitecol/subsite/_vti_bin/lists.asmx the context for requests made on that url will be relevant to /sitecol/subsite as you would expect.
However if you add a service reference to http://sharepointsite.com/sitecol/subsite/_layouts/MyCustSvc.asmx the context will be fixed to http://sharepointsite.com/ because the default wsdl generator for ASP.NET is not aware of the SharePoint virtual paths. In which case calls to SPContext in the service will not work as expected.
There is an excellent post here with examples explaining this:
Where do you deploy custom SharePoint web service files to?