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.
Related
I'ma bit stuck. Been using Visual Studio 2013 Community edition forever, to create and edit custom SCOM Management Packs in a local GIT Repository. I downloaded VS2019 (and 2017, just for luck), with a view to start using that, but it won't recognise any of my SCOM (MPPROJ) projects.
I figured I just need to update my version of "System Center Visual Studio Authoring Extensions v1.10.201.0" with the currently available download of "System Center Visual Studio Authoring Extensions v1.4.1.0", but this will not install, with the message "Another versin of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel"
Any attempt to so this, results in "The installed product does not match the installation source(s). Until a matching source is provided or the installed product and source are synchronized, this action cannot be performed" leaving me with a 'Browse' dialog box to find the original MSI"
Not sure what to do.
I currently have VS 2013, VS 2017 and VS 2019 all installed on the server, and both VS 2017 and 2019 will not recognise my SCOM Project files (labels them as 'Incompatible').
How can I continue working on my SCOM MPPROJ files in VS 2017 or 2019??
Ok, this was a few steps to fixing
Ran a repair in Control Panel>Programs & Features on the old VSAE install.
Successfully uninstalled VSAE
Reinstalled new 1.4.1.0 VSAE (x64) - Wierldy states it's v1.10.218.0 in Programs & Features
Existing SCOM Projects unable to open (new or existing) without error "Could not load file or assembly 'Microsoft.VisualStudio.TemplateWizardInterface..."
Opened VS Installer and used 'Modify' to install the 'Modelling SDK' component for VS 2019.
New error on SCOM projects:"Expected 1 exports with contract name....microsoft.systemcenter.authoring.presenter.ipresenterservice"
Opened VS Installer and ran a More>Repair on VS 2019.
Can now create a new SCOM Project, however existing SCOM projects have to be 'Reload'ed in the VS GUI to restore their SCOM MP file structure and remove the "Incompatible" status (Annoying when you have dozens of Projects).
Phew.
It's worth mentioning that before I ran these steps, I DID install MicrosoftProgram_Install_and_Uninstall.meta.diagcab and fed it the Uninstaller regkey GUID for the old VSAE that was installed. It didn't seem to fix anything, but did run a bunch of cleanup activities, so that MAY have also been a contributing factor to this resolution. Worth trying if the Repair doesn't work in first step.
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)
Our app added functionality to allow users to import certain information from an excel spreadsheet (all users will have Office 2007 already).
The development machine has Office 2007 and the developer added a reference to Microsoft.Office.Interop.Excel - all was good.
However, the build machine does not have Office 2007 installed. When the build is run on the build machine, we get the following build error: "The type or namespace name 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)"
I did download the Office 2007 Primary Interop Assemblies redistributable. But when I run that msi on the build machine, I get a messagebox saying "Please Install Microsoft Office 2007 before installing this product"
Is it really necessary to install Office 2007 on the build machine? Is there some other way around this?
Make sure the Microsoft.Office.Interop.Excel assembly is checked-in with the source code and the VS project is referencing it from the source tree and not from GAC.
After that is done, surely you do not need MS Office to be installed on the build machine, but you would need it for the application to run.
Just ask your devs to check all dll dependencies. This is a clear case of "it works on my machine" where you need to drag the devs to the machine where it is not working and point out that their documentation is lacking in the "dependencies department". If you have access to the source code or can run ILSpy on the assemblies you can propably track this down yourselve.
Safe bet is that yo just install Excel, but this is hitting the problem with a sledge hammer. Your devs SHOULD know what is really needed.....
Yes, you must have Excel installed on all machines you want to run your app on.
I'm sorry I'm english a little.
I want to redistribute .Net Framework3.5 SP1 using clickonce application(publish tab)
I check .Net Framework3.5 SP1 , but it can not find DotNetFx35Sp1Setup.exe when build process.
If i check .Net Framework4 , it works well(VS2010).
so i tried in vs2008, it works well.
How can i include .netfx35sp1 into clickonce application on vs2010 ?
How are you publishing the application from??? via visual studio 2010?? in that case.. go to your project startup file->properties->publish.. go to pre-requisites. where you will see options like download from vendor, download from the same location, download from the server location. You choose download from vendor's website and also you will see the list of prerequisite available in that popup, where you can check the prerequisites you need. you check the checkbox for .net3.5sp1 and publish.
I have installed VS 2008. When I try to build a project, I am getting an error saying:
Cannot open include file: 'afxcontrolbars.h': No such file or directory
So, I guess I need to have ribbon controls installed for this. Could you please tell me where the SDK is available for download? A link would be very helpful; I googled for it myself, but I could not find it. :(
This seems like a weird problem to me. afxcontrolbars.h is certainly included in a standard VS 2008 installation. The only way you might be missing MFC components is if you installed the Express version, which doesn't come with support for MFC.
The first thing I would do is check to see if I could create and compile a brand new, blank MFC app using one of the built-in templates. If that works, there's something wrong with your project's properties.
Also check manually in the \Microsoft Visual Studio 9.0\VC\atlmfc\include directory to see if you can locate the header file before you try to manually re-install the platform SDK. It may be as simple as Visual Studio not being able to locate the file. To remedy that, open the Options dialog, expand the "Projects and Solutions" tree, select "VC++ Directories", select "Win32" and "Include files" from the combo boxes at the top, and ensure that $(VCInstallDir)atlmfc\include is included in the list:
Of course, the ribbon control (and other ribbon-specific items) weren't added to VS 2008 until the MFC Feature Pack. You will need to download and install that in order to compile applications that take advantage of those features in VS 2008. You can download the Feature Pack here for free.
I have VS2008 on a Win7 64 bit machine.
In my case the include files where installed in the c:\program(x86) folder, but VS was installed in c:\program.
By changing the path to the "hardcoded" path
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include
it now works!