Our team has found there are some things that can't be done in the out of box SharePoint web services, so we've decided to build our own web service wrapper, to wrap around Microsoft.SharePoint.dll and Microsoft.Office.Server.UserProfiles.dll.
My problem is, those dlls are 64 bit, so the web service must be 64 bit. When I set the project to x64 bit, asp.net throws BadImageFormatException.
Is there a working web service that can call the SharePoint 2010 native libraries that I could use to see a work around, or does anybody know a work around? Most grateful!
How are the Microsoft dll's referenced? If they are in the web services's /bin folder, remove them there, so .net attempts to load them from the GAC.
Ive developed several wrappers and never had a 32/64 bit issue when i deployed the service to SharePoint.
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 a com interop dll (zkemkeeper.dll) that i have to register and use, i wonder how can i deploy that to the SharePoint server using SharePoint package?
You cannot deploy COM or COM Interop DLL to SP farm by SP solution. You need to install the component on every SP server in the farm by other means.
Create an MSI installer to be executed on every machine. MSI can be rolled out automatically too.
Provide a PowerShell script to be executed on every machine. PowerShell can be run remotely too.
Deploy a timer job with your solution that would be executed after the installation automatically or manually and would write to the registry the necessary COM stuff.
The first two options are my favourite because they shouldn't cause technical problems at the customer. The third one appears to promise installation without visiting every machine but the Timer Service user identity would need permission to write to the local registry which may not always be granted; and you'd have to resort to 1. or 2. anyway.
You should think about switching over to ASP.NET or .NET components on the long term. There are many components available in pure .NET that can be deployed by SP solutions. You can also consider pure HTML/JavaScript controls. I would probably go for the option 1. and invest the saved time to other architecture without the COM Interop.
--- Ferda
If you are using Sharepoint 2010, see How to: Add and Remove Additional Assemblies.
See also:
Deploying custom dll's in SharePoint 2010
Visual Studio - SharePoint 2010 - Include Assembly > Quick Question
Include 3rd party dll in the Sharepoint project while packaging the wsp
visual studio does not copy assembly into gac
How to install a WSP that has dependant assemblies?
Interop.zkemkeeper.dll regsvr32 error or InitializeComponent
Then you need done the step following:
Go to the website: http://www.zktechnology.com
Download ->Software Download->ZK Access for C3 panels
Extract files
Install
Open visual studio -> Solution Project->references-> Add Interop.zkemkeeper.dll
Good luck
I know there are so many questions and articles on this topic and I have searched hours and hours on the Internet so far, but I still couldn’t find the right answer for my question. I was assigned the task to investigate the development environment for SharePoint web parts by my company. The money is not an issue but it must be the proper way to do it.
Here is my ideal plan: at developer desktop, install VS2005/2008 (it is already installed), VS2005/2008 Extension for SharePoint and WSPBuilder. It is also installed a Virtual Machine and the VM runs windows server 2003/2008. WSS3.0 and SQL Express 2005/2008 will be also installed on VM.
Developer’s desktop is a web parts development environment. Developers use VS to develop the SharePoint web parts and then run the WSPBuilder, it will deploy the web parts into the SharePoint testing environment on VM. So the VM is just a SharePoint testing environment.
It looks like a good idea, however, it doesn’t work. Why? Because VS extension can't be installed on developer’s desktop as it doesn’t have WSS3.0 installed!
I definitely don’t want to install the VS on the VM, because our developer desktop has installed VS and we don’t need to have 2 VS licences for 1 developer.
Any idea what is the best way to set up the development environment for SharePoint web parts?
Thank you in advance.
You won't be able to develop for SharePoint (WSS 3.0) unless your development environment includes an installation of at least WSS. In general, development is done on a Windows Server 2003 Virtual Machine (Visual Studio is installed directly on this machine). However, SharePoint can be installed on Windows Vista and Windows 7 machines, so your development machine may be able to host SharePoint itself, but it is far easier to do this on a VM.
My SharePoint development VM has the following installed:
Windows Server 2003 R2
SharePoint 2007 (Including SQL 2005)
Visual Studio 2008
Visual Studio Tools for Office
Office Server SDK
Visual Studio Extensions for WSS 1.3
Obviously you can use WSPBuilder instead, but I much prefer VSSWSS 1.3, but that is developer preference.
I believe (should be verified with Microsoft) that the licensing for Visual Studio can be extended to Virtual Machines when used by the same developer (depending on your agreement).
An alternative for you which may or may not work depending on your priorities.
Install Visual Studio 2010 and SharePoint 2010 Foundation to your development server.
Grab a copy of Microsoft.SharePoint.dll from a SharePoint 2007 server.
Use VS2010's tools to develop a web part but manually change the reference to the 2007 dll's (+ also see "Build a SharePoint 2007 Web Part with a Visual Studio 2010 Visual Web Part Project") so you are outputing a 2007 compatible web part.
When you delploy your 2007 web part to your local 2010 server it will just work (as its backwardly compatible)
When you deploy your 2007 web part to your test/qa/production servers it will work too.
Advantages
You're working with latest greatest
version of VS and the sharepoint
tooling so you get one click deploy,
automatic creation of WSP packages
etc. Nothing against WSP Builder etc (they are great) but my moneys on vs2010 sharepoint extensions for the future.
You're ready if/when your
company moves to 2010.
You're developing on a Windows 7 machine, not a 2003/2008 server and or a VM so this has advantages for licensing, speed and ease of use (dual monitor support from VS running on a VM?)
Edit - to deploy web parts to other servers you create a .wsp package and then deploy via STSSADM or another tool (SharePoint solution installer or other admin tools).
I haven't used VSSWSS or WSPBuilder. I've always used STSDEV for SharePoint 2007. And I've always used Windows XP to do it. I don't know if VSSWSS and WSPBuilder act the same, but, as Ryan was saying, I copy whatever SharePoint DLLs I need from a SharePoint 2007 server into a Solution Folder in my Visual Studio solution. I then select Add Reference in my project and browse to the DLL.
In four years, I've never had any problems with this method. The solution packages build just fine and work on any SharePoint server. I lose the option to debug, but I'd rather stay on my machine than go into a VM or Remote Desktop.
Can Sharepoint apps be developed in a Visual Studio 2010 dev box only or does the dev box need to connect to a Sharepoint server? Can the Sharepoint Server be a stand alone machine (no domain controller between the two machines)?
The best practise for SharePoint development is to use a virtual server that contains the SharePoint install itself (and a copy of the portal you're working with), because assuming you are programming directly against the SP API, you will need to be executing your code on the machine that contains the Sharepoint installation itself.
You can program against SharePoint from a non-SharePoint machine through the use of the standard set of SharePoint web services provided, and you can of course create your own services (again sitting on the SP box/VM) to interrogate too. The catch to this approach is that you'll be dealing with return types that are primitive or XML based and you won't have the luxury of SP objects, for example SPUser, SPSite, etc, but for simple query operations at least this is not a bad approach.
IMHO, however, you've far greater flexbility programming against the API itself (Microsoft.Sharepoint.dll) so I'd advise you to get a VM going with all the necessary installs. Yes, it's a pain and time-consuming to set up, but well worth it.
As for Stand-alone options: SharePoint 2007 is not supported on anything non-server in terms of OS, so you'll need something like Server 2008 in order for it to work. SharePoint 2010, however, whilst claiming to only work on Server 2008, can actually work on Windows 7 (Pro and above) with a few hacks. You also have the benefit of 'sandbox' feature deployment in 2010, where you don't in 2007, meaning dev work is more cleanly isolated and less of a risk to a farm as a whole.
Good luck!
You can develop for SharePoint 2010 using VS 2010 using a stand alone setup - this is supported by Microsoft and very much recomended. Infact most of the tools built into VS2010 that will make your life significantly easier will only work with a local copy of SharePoint 2010.
MSDN - Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7...
Yes, if you have Windows 7 or Vista (you need WAS - Windows Activation Services). We have tried it but found that it was better to develop on a Windows 2008 with your own AD.
It will depend on what you are developing, for webparts you will not notice the difference. You will notice the difference when working on the security part og the app.
Sahil Maliks book has a whole chapter on the different options.
you can do sharepoint development by copying certain dlls to your local enviroment but to my understanding this is unsupported and the recommended practice is to use a virtual machine or development on the machine in which the service resides.
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