I'd like to develop SharePoint 2010 web parts without local SharePoint installation. I mean I don't want to install SharePoint server because I don't need it and it's so huge.
I found some questions about this, but I still can't get it working. I found a blog entry about this: http://techblog.hk.agenda-asia.com/2010/10/29/create-sharepoint-project-without-install-sharepoint-server/
I tried to follow the instructions from that blog. Now I can create SharePoint 2010 projects with Visual Studio. Problem is that Visual Studio cannot find SharePoint dlls. Even if I copy them to local directory and add that folder to registry with key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v3.5\AssemblyFoldersEx\MyAssemblies (like blog entry adviced)
How could I tell Visual Studio where SharePoint dlls are?
You can get the DLLs from sharepoint from the ISAPI folder in the 14 hive:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI
Just copy the dlls to your local computer and reference them in your project to compile.
You will realise it's a great pain when you are debugging/deploying your projects as you wont be able to test your code locally.
UPDATE: The Sharepoint 2010 Evaluation machine is not available anymore. So the information bellow is not current anymore. The best option now is to get Sharepoint 2010 from MSDN, if you have a subscription obviously.
My advice is to get Microsofts 2010 Information Worker Demonstration and Evaluation Virtual Machine (SP1):
http://www.microsoft.com/en-au/download/details.aspx?id=27417
It's a virtual machine with Sharepoint 2010, and it comes with all the tools you need like infopath, and visual studio pre-installed.
The only problem is you will need 2008 server r2 to run it.
I have managed to successfully convert the machine to VMWare and I am happily running it under windows 7 by following instructions from this post:
http://sharepointyankee.com/2010/06/03/converting-the-sharepoint-and-office-2010-information-worker-virtual-machines-to-vmware-from-hyper-v/
Make sure you read the comments on that post as there are a couple of gotchas.
Also make sure you have a somewhat grunty machine. I am running it with an i7 with 8 gig ram, SSD, with 4 cores allocated to the VM and it runs smooth.
Ok, to answer the original question:
Copy the SharePoint dlls from an actual SharePoints server (you'll need one of those anyhow) from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI
To your dev machine - you do NOT need to place them in a similar structure - choose whatever you want.
In visual studio either reference those dll's directly (add reference, browse) or add a folder to the "reference paths" in the project settings.
If you are multiple people working on the project, you may have problems if you are using different versions/service packs of the SharePoint dlls - then ensure that the reference has the "specific version" flag set to true (every reference)
Related
I installed Office 2013 and VS2013 on Windows 8.1 - when I now open old Projects which reference the version 12 PIAs (for Office 2007) these are missing in the references since VS2013 does only install Version 14 and 15 of the PIAs.
Since I want to Keep using PIA 12 I do not want to change the references. Instead I'd like to Register the Version 12 PIA's with VS2013. How can I achieve this?
I already tried using the PIA redistributable, but it does not want to work unless I install Office 2007, too (which I don't want). I can get a copy of the dlls from some other system, but how do I register These with Visual Studio 2013 (I don't need them in the GAC, I think, just in VS2013).
As far as I know for the PIA some COM class ID's should be recorded, I just don't know how/which.
Edit:
Right now the PIA dlls are referenced just by Name and Fingerprint/public key (no hint path). When I open the reference Panel in VS2013 they will Show up, can be selected and work. They seem to be registered somewhere so VS2013 can find them. I just want to replicate this on other Computers.
I've got the exact same setup, a machine with Windows 8.1 and only Office 2013 installed. No trouble at all getting the Office 2007 PIAs installed. Do beware that this is a two-step process. After you downloaded PrimaryInteropAssembly.exe from the Microsoft server and started it, you prompts you to give a directory to store intermediate files. Navigate to that directory, right-click the o2007pia.msi file and select Install to get them actually registered.
It isn't the only way to get them onto your machine. If you have another machine with the PIAs installed then create a dummy project and add the references to the Microsoft.Interop assemblies you need. Select them and ensure that the "Embed Interop Types" property is set to False and the "Copy Local" property is set to True. Build the project, you'll get the interop assemblies in the bin\Debug directory. Copy them to your machine and use the Browse button to add a reference to them. You always want the "Embed Interop Types" property set to True in your real project so you don't have to deploy the PIA on your user's machine anymore. Check them in with your project so you don't lose them again.
UPDATE: PIAs are obsolete since .NET 4.0 and VS2010. Check this post for the details.
How do I create a Visual Studio Project for Development on my Local PC that links to Existing files and folders on a Server?
My employer has a large website. Most of that girth (close to 100 GB) is contributed to Portable and Image document (i.e. PDF and JPEG) files, but there are also numerous web files (.html, .aspx, .php, etc).
We have the following folders:
a WORKING folder that contains everything that is "Live" on our web server.
a BETA folder that contains newest technologies that are being tested and tried.
a DEVELOPMENT folder that contains numerous copies of projects that are being worked on by the different developers.
Developers are allowed to use whatever tools they prefer, so we have people who develop using Notepad++, Dreamweaver, Komodo, Zend Studio, and (now) Visual Studio.
It is NOT OK for me to create Visual Studio Projects for myself on the network servers. Other developers using other tools are not creating solution files or \bin and \obj folders on the servers, and I certainly should not be either.
So, to work on a file in Visual Studio, I use Windows Explorer to browse to the location, then I open it in the IDE.
However, this causes me to lose a lot of the power of Visual Studio - particularly if other classes used in this file, because I would have no access to the Intellisense for that class and I cannot simply Right-Click and go to definition.
Also, since each development environment is so large, I can not copy them to my laptop with its high tech 125 GB Solid State Drive (should be interesting to read that in a couple of years).
What I would like to do is create the Visual Studio Projects on my local drive, and then have them reference the files and folders on our network.
I've looked and found these similar questions, but my goal is slightly different:
Working efficiently on remote projects in Visual Studio
How do I add an existing directory tree to a project in Visual Studio?
How to "Add Existing Item" an entire directory structure in Visual Studio?
These are all great topics, but none of them show a way to create a local project that uses remote files.
It would seem that developers in large company teams would have already developed a way to do this, and that I just do not know what it is called.
I have found a way to do this!
For a long time, I was working with 2 sets of folders. One for our repository and one for Visual Studio.
I'd make changes in Visual Studio, then copy those working files over to the repository folder.
That was time consuming! Very.
Here is how I found to fix it: Open the Visual Studio Project file (*.csproj, *.vbproj, or *.phpproj) in NOTEPAD with Visual Studio closed.
Locate the <ItemGroup> tab, and change every path to be from the one shown to one that uses a relative path to get to the actual files.
Notepad's Replace... CTRL+H will save you hours here!
It makes a funky looking project environment, but it works!
If this helps anyone else or if it were even something you didn't know you could do to manipulate Visual Studio, kindly vote it up.
I have references to
using Microsoft.VisualStudio.TestTools.UITest.Extension;
using Microsoft.VisualStudio.TestTools.UITesting;
But I'm building on a server without Visual Studio installed.
My builds are failing because these dlls can't be found (their path is in the VS install directory on my local machine)
Does this mean VS is required to run these on the build server? Or can I just copy the dlls into some project folder and add them as references?
The recommended approach is to install VS on the build server and the licensing is such that you are able to do that. The team know that this is not an ideal solution but it's the only one we have today. Note that the build server images provided by Microsoft in the hosted environment (tfs.visualstudio.com) have VS2012 and VS2010 installed into them for exactly this type of reason.
Here is what we are trying to do:
In a TFS collection we set up a TFS project “BuildBusinessWebsite”. For this project we will have .Net solutions, SQL Server Reporting Services (SSRS) reports, and SQL Server Integration Services (SSIS) packages. (I have to do development on all three.) We have chosen to set up a folder structure like this in Source Control Explorer with solutions and code in each directory folder:
BuildBusinessWebsite
Development
Application
SSRS
SSIS
Test
Application
SSRS
SSIS
Production
Application
SSRS
SSIS
Now, we are currently developing the SSRS reports and the SSIS packages using Visual Studio 2008 and the application is being developed in Visual Studio 2010. When you connect the second Visual Studio 2010 environment to the same working directory (Local Path: Not mapped) you get the error “The path … is already mapped in workspace …” issue because it is already mapped to the Visual Studio 2008 directory. I need both environments mapped to the same directory as I do not want to keep multiple directories on my machine up to date with “Get Latest”. I am also currently testing the migration to Visual Studio 2012 where it is also asking me to map another location for TFS. My current work around is to create another layer of folder mappings as C:\TFS2008, C:\TFS2010, and C:\TFS2012 with the folder structure above in each. Is there a way to consolidate all these for one location for all the code?
Second issue related to the above is with branching and merging: If there is some way to fix the above then this one is moot, however, when pulling down the folders above from source control and you are utilizing branching and merging, the branching and merging connections between prod, test, and dev do not seem to pull from TFS. They seem to be local to my workspace and machine. Considering the example above where I branch my application from Production to test and test to Development in Visual Studio 2010, when I use Visual Studio 2012, map the Source Control Explorer to another location on my hard drive, and “Get Latest”… After it comes down I lose my branching and merging having to set them back up. Is there a better way to set this up?
Thank you all ahead of time for reading this and thoughts you might have would be greatly appreciated.
TFS Workspaces are uniquely identified by:
Workspace Name
Workspace Owner (AD Account name)
Computer Name (The Computer which it is on)
Team Project Collection it is in
The workspace mapping should have nothing to do with the "environment" you are working in. You should either use the TF Admin command to create your workspaces or go to File->Source Control->Advanced->Workspaces... in Visual Studio. Also, create only 1 workspace and do it at the root folder.
I'm developing a device application, using a connection with a 'regular' Sql Server 2005 (not a Compact DB). Whenever I try to open SqlConnection on Windows CE (a Datalogic Memor CE), I’m getting a MissingMethodException: Can't find PInvoke DLL 'dbnetlib.dll'..
This seems to be a deployment issue. In my project I include:
C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v3.5\Devices\Client\System.Data.SqlClient.dll
The file System.Data.SqlClient.dll does get deployed to my application directory, but there is no sign of dbnetlib.dll.
When I Google this Exception, I mainly get these suggestions:
This is a Microsoft bug, when Visual Studio 2005 and 2008 are installed. Resolve by (re)installing 'SQL Server Compact 3.5 Design Tools' http://support.microsoft.com/kb/945371.
I have Visual Studio 2008 and 2010 - AFAIK 2005 was never on my system. I tried un- and re-installing the SQL Server Compact 3.5 Design Tools (\WCU\SSCE\SSCEVSTools-enu.msi)
Edit: Since the Devices\Client-directory is installed by 'SQL Server Compact 3.5 for Windows Mobile' (SSCEDeviceRuntime-ENU.msi), I downloaded and also tried un- and re-installing the base version, SP1 and SP2, but there was still no deployment-difference.
Another suggestion is to install the SQL Client separately using a (platform-dependent) .cab (like sql.wce5.armv4i.CAB) and this dbnetlib.dll copied from e.g. C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v3.5\Devices\Client\wce500\armv4i to a persistent start-up directory (like \Backup\Startup on this Datalogic).
Without trying, I think this might even be limited to including this platform-dependent dbnetlib.dll, since System.Data.SqlClient.dll does get deployed.
But this seems more like a a work around to me, deployment should take care of this. Drawback of this work around seems:
an install is executed at each cold boot (and maybe even at a warm boot)
adding (more) platform (and version) dependency to my project by explicitly defining the .cab
The question is: do you know a solution for Visual Studio to deploy correctly?
Another question might be: do you have an opinion about this work around?
(BTW: the DB-connection works fine on a Datalogic Memor WM (Windows Mobile), so I guess the appropriate .NET-library is already installed on that device.)
Visual Studio generally does a good job of working out what to deploy, but it isn't fullproof. For example if the DLL is linked dynamically then it has no way of knowing that it is required and won't deploy it: it also routinely and silently fails to deploy files to the Windows directory.
I would recommend that you manually deploy the file during development. I generally prefer to do this anyway to make sure I know what has been deployed (the joy of batch files...).