I want to know if Microsoft.Office.Interop.Access.Dao.dll version 12 is the same thing as acedao.dll. If not where can I find acedao.dll and add a reference to it in a C# WPF project?
I have no idea if the Interop dll is the same as acedao.dll.
Visit 2007 Office System Driver: Data Connectivity Components to download the dll as a separate component.
Note though that Jet 4.0, msjet40.dll, is a Windows operating system component and Windows requires it. It is present in Windows 2000 through to Windows 7. Whereas the acedao.dll must be installed. Depending on your overall objective you may find that msjet40.dll works for you.
Have a look here:
"C:\Program Files\Microsoft
Office\Office12\acedao.dll"
Related
I've created an office add in using Visual Studio 2015. The add in works perfectly with MSProject in debug mode.
I've published the add in following the instructions here. So far so good.
Now I'd like to release it to the Microsoft Windows Store. I've logged into the Seller Dashboard and I pretty much fall at the first hurdle.
It asks for the app package manifest file. TBH I'm not sure which file it wants exactly, so I tried
xxx.OfficeAddin.vsto file in the root of the "publish" directory
xxx.OfficeAddin.dll.manifest in the publish/Application Files/xxx.OfficeAddin_1_0_0_2 directory
xxx.OfficeAddin.vsto
also within the publish/Application Files/xxx.OfficeAddin_1_0_0_2
directory
I assume it wants No2 but it didn't work so I tried them all. None of them work and all result in the same error:
Your manifest does not reference any supported Office Add-in namespace. The most recent version is http://schemas.microsoft.com/office/appforoffice/1.1.Learn More
Googling this error in quotes returns nothing, without quote - a load of unrelated results.
I'm completely stumped now - has anyone managed to do this?
You cannot add VSTO desktop applications to the Windows store, but may be able to do so soon.
The Windows Store was designed for installing applications that would run in private sandboxes that would keep apps isolated (in case of issues) from your operating system and other applications. However, Desktop applications often have registry entries, dll dependencies, and other client-side requirements. Because the Windows Store cannot accommodate these OS-related and client-side requirements, desktop applications cannot currently be distributed via the Windows Store
Fortunately, Microsoft is finally addressing this issue. They are in the process of finalizing Project Centennial, which will allow one to convert desktop apps for distribution via the Windows Store. It does this by providing a separate registry for desktop apps and a way for dlls to function without hurting other applications.
As of this writing, Microsoft has withdrawn the preview version of their Project Centennial Desktop App Converter. I am hoping this is in preparation for releasing a stable version.
Will Project Centennial allow VSTO add-ins to be sold via the Windows Store? I am hopeful, but this is not certain. We should know more within the next couple of months, if not sooner.
Update: June 8, 2016
At Microsoft's dotnetConf 2016 John Sheehan stated that VSTO add-ins would not be supported in version 1 of Project Centennial. He added that plug-ins (his term) that leveraged other desktop technologies would be able to be converted by the Project Centennial Desktop App Converter some time after Project Centennial's initial release (now slated to be concurrent with Window 10's 1st anniversary release in July 2016). Mr. Sheehan did not elaborate on whether VSTO add-ins would specifically work with later versions of Project Centennial, but he did indicate that compatibility with software that leverages other desktop technologies is definitely on the Project Centennial road map.
I have created a VSTO Add-In. It will add new Tab to ribbon. Currently, it is working fine in Windows system.
I don't know whether it supports to Mac(iOS) operating system.
Can anybody please suggest me about it support? If it doesn't, what I should use to create project which support both windows and Mac(iOS)?
The straight answer is that VSTO add-ins are based on the COM technology which doesn't exist on MACs. It is for Windows OS only. VSTO in particular and COM addins in general donot have the ability to work on the Mac OS or in iOS.
The architecture needed to invoke add-ins based on .NET controls is fundamentally different from the BSD Unix based ones that Mac uses.
The twist to this answer is if you are willing to stretch your programming towards Office Apps you will get what you are looking for.
This brief from MS will help you with the requirements for OS X desktop
Word for Mac version 15.18 (160109) is required to run Office add-ins.
Excel for Mac version 15.19 (160206) is required to run Office
add-ins.
Source : https://dev.office.com/docs/add-ins/overview/requirements-for-running-office-add-ins
I have installed RSAT for Windows 10 and this should give me the above class lib. But I cannot find it!
This article seems to be outdated, its talking about win vista and win7!. Following this MSDN Article under %windir%\assembly\gac_msil I should find the necessary assembly to add to my Visual Studio Project. Unfortunately I do not have an assembly named Microsoft.GroupPolicy.Management there.
I can start the server manager and I can also open the Group Policy Management console, but I can't find the assemblies! Anybody knows what I am missing? Where can I find these assemblies under Windows 10?
I had the same problem. if you are still looking, on Windows 10 RSAT installs the Microsoft.grouppolicy.management dlls into %windir%\Microsoft.NET\assembly\GAC_MSIL. You can browse to this dll to add it as a reference to your .Net project. Also you don't need to "Turn Windows features on or off" as RSAT doesn't appear in the list and this was installed by default. The Microsoft article is out of date as you mention. Hope that helps.
I have build C# windows form application using visual studio witch is simple outlook plugin installer.
It does these steps:
generates GUID and stores it to windows registry (for logging purpose later in outlook plugin)
Downloads actual outluck install files
Launches outlook plugin installation
The problem is that I can run this setup if .net framework is not installed. Is there a way of checking is framework installed? Or maybe there is a way to convert this app to native windows application (without .net dependencies). Or maybe it is possible to include needed dll's only?
I have tried using mono mkbundle, but I am getting strange errors in windows like Program too big to fit into memory or something with wrong application architecture (x64 X86).
I have also found some commercial tools for that like .net fuze. So maybe there is free alternatives witch does something similar?
Or maybe this single file installer idea is wrong? Maybe I should use something different?
I have a huge problem on one of my winform application. Someone who use my application works on windows 7 64bits and apparently it directly crashes when the application is launching.
My application works correctly on :
-Windows XP
-Windows Vista
-Windows 7 (32bits).
I developped the application on Visual C# express 2005 (.NET 2.0).
I am wondering if there is anything I can do to recompile my application to make it work on windows 7 64bits.
I am sorry, I have no access to the computer of the person (so I can't check, exception or anything like that). I am pretty sure that this issue is known that's why I'm asking you right now.
Does anyone have an idea ?
Thank you by advance for your Help
Regards,
Joze
In project properties setting window, select tab Build and change Platform target to X86. Republish..
EDIT: to the down-voter
By doing this Windows will know your program is designed for X86 use and will install it accordingly. (I've done this with Clickonce, and it works..)
Likly you use some interop x86 DLL or COM object. Try setting for your executable Target Platform x86 (not Any CPU as it is by default).
Do you use any unmanaged (com) components in your application?
If so, most likely you're including the 32bit version. If that's the case, you will have to compile 2 different versions of your program, one including the 32bit components, and the other including the 64bit components.
If that's not the case, it means you're using some platform specific code somewhere. More details about your application could help clarify the problem.