Sorry, my English is bad, but i will try to explain what i mean.
I made EventReceiver on Developer PC on VisualStudio 2012 and it's work on my developer's SharePoint2013 Server.
I made WSP packgage, deployed it to Client's SharePoint 2013 Server, activated feature and get an Error.
Could not load type 'Microsoft.SharePoint.Administration.SPDiagnosticsService' from assembly 'Microsoft.SharePoint, Version=15.900.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'.
How i understood it's SharePoint.Dll version is another, but i can't find this version and don't know where it's on clients server.
I have the same Error. I copied dll files and had the same Error. Installed Visual Studio on clinet Server and it didn't help. I think it's server configuration bad.
To load SPDiagnosticsService, you need to ensure that your solution is deployed to the Farm.
To do check the settings, view the project properties, make sure Sandboxed Solution is set to False
Related
I am a system admin tasked with migrating Classic ASP based web application from Windows Server 2003 (IIS 6) to Windows Server 2008 r2 (IIS 7.5)
The application is very old written in around 2002-03 and the concerned developer people are not around anymore to let me know anything related to this Web Application.
After lot of trial and error, I have been able to get the Web Application running on 2008 r2.
While navigating through application, I am getting various errors which on further investigation I understood are related to DLLs which the Web Application is invoking.
My issue is, I don't know what all DLLs are used/invoked on the source server, which I need to copy & register on the new server.
I tried to use DependancyWalker but I am not able to find a way to use this tool for Web Application.
I would really appreciate this community's help in this regard.
I found out a simple way of finding the DLLs which are specific to my Web Application.
I got a small freeware utility called as RegDLLView from Nirsoft.net which lists all the DLLs which are registered with the Server with File Paths, Description, Company name, etc details.
I found out all the DLLs which my Web Application is invoking by checking the company name and paths of all the DLLs which were listed.
Now I just have to copy these DLLs to my new server and register these on the new system.
It's not rocket science.
When you find a COM component dependancy you can use the ProgId to identify and locate the DLL which is registered in the Windows Registry.
The only DLL dependancies come from COM component DLLs and these can only be invoke in Classic ASP / VBScipt with the
Server.CreateObject("ProgId")
and
CreateObject("ProgId")
respectively.
Wrote about this extensively here
Error ASP 0177: 8007007e Server.CreateObject fails for COM DLL
I have been tasked with setting up a SharePoint 2013 site being a straight MVC developer has me scrambling to figure out how to implement a solution that works for everyone involved.
We have a server with SharePoint on it and visual stuido however RDC only has 2 connections (company will not pay for more connections, tried that route) and we have the potential for 8 developers to be logged in at once.
our local machine setup is windows 8.1 with visual studio 2013 on it.
I read somewhere you can do remote connections to SharePoint but have no clue how to set that up or if it's even possible for use.
if anyone can help point me in a direction that would be great.
If you are strictly developing Apps you can develop remotely and this TechNet covers the step-by-step for it (configure the server and infrastructure for Apps, create a developer site and give your Devs the required permissions).
If you want to develop components that use the server side Object model (Microsoft.SharePoint.dll) you MUST do so from a SharePoint server.
You can try to copy the DLL over to your dev machine, and you can successfully build. With this, though, you will lose many of Visual Studio's integrations and will not be able to deploy or debug from Visual Studio
We have a SharePoint farm configured with one SQL server, an Application server and one Web Front End. All assemblies run from the GAC on the WFE, except one. This one dll has to be forced (using gacutil) into the GAC on the App server in order to see changes in our SharePoint application.
My question is, what determines that this dll must run on the App server and not with the rest on the WFE? I assume because of this, I cannot debug in Visual Studio from the WFE. Do I have to install Visual Studio on the App server as well?
When setting up a timer job, it's possible to use the constructor to specify a specific server. That's likely how things got set up for this solution and associated .dll file. More info on that here:
http://www.martinhatch.com/2009/08/sharepoint-timer-jobs-and-multiple.html
As for adding Visual Studio to servers on your farm, if this is your production farm I do not recommend doing this. If you really need to debug in production (you really, really should have a development box set up for this), do it via remote debugging.
I need to have all the documents in Sharepoint opens in client applications. I set the appropriate setting in the admin page, but it doesn't work for all users. Also I tried to set this in library settings, result was similar.
I think the reason may be on a client side, but I haven't found it. All users with this trouble have IE7 and MS Office 2003.
Does anybody know, how i could handle this?
I would think that the server is checking if the user has Office installed locally. This is achieved by trying to activate an object from the ActiveX control installed by Office locally. You can find this DLL under c:\program files\microsoft office\office12[14]\OWSSUPP.dll. If this dll fails to load, for instance, missing or not registered probably, SharePoint assumes that no local client software is installed. You can register the DLL or run repair on the Office installation, that should fix the problem
Recently I had to develop a SharePoint workflow, and I found the experience quite honestly the most painful programming task I've ever had to tackle. One big problem I had was the problems I encountered when I had to step through it in the debugger.
There's an article on how to debug a SharePoint workflow here that tells you how to set breakpoints etc. This involves copying the .pdb file into the GAC alongside the .dll file containing your workflow. You have to do this from a command prompt (or a batch file) because Windows Explorer doesn't let you view the relevant subdirectory of c:\windows\assembly.
However, if you do this, the next time you try to deploy the workflow from within Visual Studio, it complains that it can't be deployed because "the file may not be signed" and if you attempt to copy the new version of the dll into the GAC, it tells you that the .dll file is locked.
I've found that some of the time, you can get round this by doing an iisreset, but on other occasions you have to restart Visual Studio and there have been frequent times when I've even had to reboot the computer altogether because some mystery process has locked the file. When I don't use the debugger, on the other hand, everything works just fine.
Does anyone know of a simpler way of debugging workflows than this?
I've got a lot faster developing SharePoint-Solutions in general (not only Workflows) when i started using WSPBuilder. WSPBuilder has a Visual Studio Addin called WSPBuilder Extensions and in my opinion the WSPBuilder Extensions do a better job than the infamous Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2. Thanks to the WSPBuilder Menu deploy/upgrade/uninstall of a solution is just one click away!
The SharePoint team is currently working on MOSS extensions for VS 2008 which will allow this type of functionality. This was available in VS 2005 with MOSS extensions, but has to be run off Windows Server with a full MOSS installation and the correct permissions set.
One thing that would really help is if the SharePoint team provided interfaces for the SP-specific workflow services needed to run SP workflows. This would allow you to mock those interfaces and run the workflows outside of SP proper. AFAIK, you can't do that today.
I've personally found SharePoint extremely painful to develop against... not just with workflows, but overall. I understand the administrative wins and the end user productivity, but it's a fairly dreadful experience for Joe .NET Developer.
As for speeding up the IIS reset, Andrew Connell has some tips here as well
http://www.andrewconnell.com/blog/archive/2006/08/21/3882.aspx
This brought my IIS reset time from 10+ seconds down to less than 2 seconds.
I'm not sure you need to get the pdb file into the GAC. (At least, the fix I'm about to describe works just fine for debugging SharePoint web parts in VS2005, which have a similar problem.)
There's a checkbox marked "Enable Just My Code (Managed Only)" in Tools-->Options-->Debugging; if you uncheck it, then Visual Studio will happily load your pdb's from the bin\Debug folder where it built them. Probably. Can't hurt to try, anyhow...
Check out STSDev on CodePlex by SharePoint MVPs like Ted Pattison, Andrew Connell, Scot Hillier, and more.
STSDEV is a proof-of-concept utility application which demonstrates how to generate Visual Studio project files and solution files to facilitate the development and deployment of templates and components for the SharePoint 2007 platform including Windows SharePoint Services 3.0 (WSS) and Microsoft Office SharePoint Server 2007 (MOSS). Note that the current version of the stsdev utility only supports creating projects with the C# programming language.
Keith