Recently, I have been escalated to work in a legacy project. This application is a plugin to Enterprise Architect that extracts the content to a .doc file. The point is, I tried to reference dll from different places, without success.
The error:
The type or namespace name 'Word' does not exist in the namespace 'Microsoft.Office.Interop' (are you missing an assembly reference?)
The places I have tried reference:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Visual Studio Tools for Office\PIA\Office14\Microsoft.Office.Interop.Word.dll
C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Excel\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll
I am using Vistual Studio 2010 and I have Office 2013 installed in my machine, but also tested in a machine with Office 2010.
Appreciate any help.
Update:
Everywhere in the code the word 'Word' is underlined and the compilation error is above.
using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;
using Word = Microsoft.Office.Interop.Word;
using Office = Microsoft.Office.Core;
namespace EATec.Helpers
{
/// <summary>
/// Classe que manipula documento Word via Interop
/// </summary>
public class MSWordHelper
{
private static object format = Microsoft.Office.Interop.Word.WdOpenFormat.wdOpenFormatAuto;
private static object wrap = Microsoft.Office.Interop.Word.WdFindWrap.wdFindContinue;
public static Microsoft.Office.Interop.Word.Document OpenDoc(object fileName)
{...
}
Legacy apps built against older versions of office may be doing something like (C++):
#import <msword9.olb> rename("ExitWindows","ExitWindowsWRD") rename "FindText","FindTextWRD") rename("ReplaceText","ReplaceTextWRD") rename("RGB","RGBWRD")
When I set up a new machine, I have a bat file to re-register the old files:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regtlibv12 "C:\Source\Office 97 dlls\mso9.dll"
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regtlibv12 "C:\Source\Office 97 dlls\msword9.OLB"
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regtlibv12 "C:\Source\Office 97 dlls\vbe6ext.OLB"
This has to be done when it's a newer version of Office installed on the PC.
Please note that regtlibv12 might not be on a windows 8 PC, and will need copying over from your old PC.
(Know this is nearly a year old, but just setting up a new PC at the moment...)
Related
Has anyone ever run into an issue with .net 4.8 (c#) throwing "too long path" errors like below when run from a class library project. The same line of code is working fine for me if I run it from a windows forms project.
the error is below
"The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters"
The code I'm using to get the error is pretty simple. StrPath is a valid path that is say 350 chars long. ("c:\<350 Char path and filename>")
string a = Path.GetDirectoryName(strPath);
That's the simplest example, but it also happens when using any File or FileIO method like File and FileStream where I reference the long path.
Things I've tried
Most recommendations from https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN
setting the long path registry key
Including app manifest with settings to recognize long paths. (there were two different types of these I found on the net, neither worked)
prefixing with "\\?\"
Looked at what mscorlibs are being referenced by both the windows forms and the exe calling the class library dll. Both were identical and referenced 4.8 libs.
Both projects succeed when I use a shorter path than 260. So it is really a path len issue I think. It just seems to behave as if I'm using an older version of .net when run from the class library.
I call the class library from within a native C++ app (its a com interop). I can also get it to happen if I make a class library with that code into an nunit text fixture and call it from nunit-x86.exe. So the code would be as below for that. And fails when calling GetDirectoryName
using System.Text;
using System.Threading.Tasks;
using NUnit.Framework;
using Omtool.Properties;
using System.Diagnostics;
using System.IO;
using OmXceedInterop;
using System.Windows.Forms;
namespace XceedTest
{
[TestFixture]
public class Class1
{
[Test]
public void Test()
{
string strPath = "C:\\Kit\\BlahServer\\Work\\CompoundFile\\Xceed\\2a0bb008-397b-476a-8e89-96caa7a11319\\HLCUVL1221104974\\THIS_NAME_IS_TOO_FRACKING_LONG_TO_BE_IN_ANY_WAY_USEFUL_YOU_SHOULD_BE_A_FRACKING_SHAMED_OF_YOURSELF_HLCUVL1221104974_Container Inspection_NANDA TILES,SL-DOCUMENTO CONTENEDOR-NEXP-220199-STYLE ACCESS-FLOOR DECOR-BAYTOWN TX-NO.1001367035.pdf";
int b = strPath.Length;
string a = Path.GetDirectoryName(strPath);
}
}
}
Again, the exact same lines of code work from the forms app but fail when called from the class library. There is something different about these two projects or perhaps the context under which they run that I'm just not understanding.
[EDIT]
It has to be the context. When I run my nunit class from the forms app, there is no path error. When I run that same assembly from nunit-x86.exe, I get the pathing error. It seems to depend on what's calling the class library as to whether I get the error or not
Goal: Create a C# Assembly called TestDLL.dll that can be installed to any computer such that MS Access VBA can use it via COM.
Environment:
Windows 7 64-bit.
MS Office Professional Plus 2010 Version: 14.0.1753.5000 (64-bit).
Visual Studio 2010 Professional.
TestDLL.dll assembly code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
namespace TestDLL
{
[ComVisible(true)]
[Guid("7CAAEF3F-F867-445B-B078-5837A833620A")]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface IGreeting
{
string SayHello();
}
[ComVisible(true)]
[ProgId("TestDLL.Greeting")]
[Guid("73D4187A-F71D-4E45-832A-6DD9F88CC59B")]
[ClassInterface(ClassInterfaceType.None)]
public class Greeting : IGreeting
{
[ComVisible(true)]
public string SayHello()
{
return "Hello, World!";
}
}
}
A WinForms project added to the solution successfully calls the SayHello() method.
TestDLL project properties:
Application / Target Framework - .NET Framework 4
Application / Assembly Information / Make assembly COM-visible: false (I only want certain public classes within the assembly to be COM-visible, not ALL public classes. Even though for this demo there's just one class and I do want it to be COM-visible. The code above should have taken care of that.)
Application / Assembly Information / Title and Description and Company and Product are all "TestDLL".
Build / Platform: Active (any CPU)
Build / Platform target: x86
Build / Register for COM interop: false (I don't want it to work on MY computer only but ALL computers. Thus I want to register the assembly when it is INSTALLED, not when it is BUILT.)
Signing / Sign the assembly: false (I want the assembly to live in the install folder, not in the GAC.)
A peek at AssemblyInfo.cs reveals:
[assembly: ComVisible(false)]
[assembly: Guid("6bf701f9-3953-43bb-a8af-1bdf7818af3c")]
The assembly is built.
Then a type library is created using the Visual Studio Command Prompt (run as Administrator) with this command:
tlbexp "C:\(path)\bin\Release\TestDLL.dll" /win32 /out:"C:\(path)\bin\Release\TestDLL.tlb"
A Visual Studio Installer project called SetupTestDLL is added to the solution.
On its File System tab, Application Folder, TestDLL.dll is added. This automatically also adds TestDLL.tlb.
Right-clicking TestDLL.dll in that Application Folder allows opening a properties window.
There, Register: vsdraCOM
When right-clicking TestDLL.tlb in that Application folder to get the properties window:
Register: vsdrfCOM
(I'm guessing that vsdraCOM means register the assembly and vsdrfCOM means register a file for COM.)
One more file is added to the Application folder: TestDLL.pdb.
SetupTestDLL is built.
Browsing to its output folder, reveals setup.exe and setupTestDLL.msi.
Right-click setup.exe and Run as administrator.
A dialog box displays the correct install path and the correct "Install for everyone" option.
The install completes successfully.
In the Control Panel / Programs and Features, TestDLL is now listed. Its publisher is listed as "XYZ". Where did that come from? Evidently from the "Manufacturer" property of the SetupTestDLL project's property window. I created that value only there in the entire solution.
In C:\Program Files (x86) there is now an "XYZ" folder, under which is a TestDLL folder, and in that are the three files.
Launch MS Access. Open an existing database and its existing code module.
From the Access code window toolbar, choose Tools / References.
TestDLL is found in the Available References listbox. Click its check box and click OK.
Click the Object Browser button on the code window toolbar.
is selected in a dropdown list. Change it to TestDLL.
The class "Greeting" is shown with its method "SayHello". So far, so good.
Close the Object Browser.
Create this procedure in the code module and try to run it.
Public Sub Test2()
' Dim o As New TestDLL.Greeting
' The above is early binding. It should also work
' since we set a reference.
Dim o As Variant
Set o = CreateObject("TestDLL.Greeting")
' The above is late binding.
Debug.Print o.SayHello()
Set o = Nothing
End Sub
Result:
Whether early or late bound,
ActiveX Component can't create object.
What's wrong?
I was just going to add a comment, but I don't have enough reputation points so I'll just post this as an answer and remove it if necessary.
I'm not familiar with Visual Studio Installer projects, so I'm not sure if it is registering the assembly correctly. Have you tried using regasm to register TestDLL? Something like:
regasm /codebase TestDLL.dll /tlb:TestDLL.tlb
64-bit MS Office cannot use a 32-bit COM DLL early bound, but with a reg hack involving DLLSurrogate, it can use it late-bound. I got that to work.
I am stuck in a problem in which I am using Amazon SDK for .NET 4.5 on VS 2012
What my problem is that my code does not resolve ElasticTranscoder namespace
-I installed SDK 3 times all old to latest versions
-Checked on VS 2010 and 0n VS 2012
-Tried adding ref like 100 times again n again
Cleaing and rebuilding solutions
It never changes.
I am stuck for two days now.
Help me in finding the correct way to resolve this class AmazonElasticTranscoderClient
Anyone?
public void CreateJob(string Path, string bucket)
{
string accsessKey = CloudSettings.AccessKeyID;
string secretKey = CloudSettings.SecreteKey;
var etsClient = new **AmazonElasticTranscoderClient**(accsessKey,secretKey, RegionEndpoint.USEast1);
}
Hate to ask the obvious, but do you have these using statements at the top of your file:
using Amazon.ElasticTranscoder;
using Amazon.ElasticTranscoder.Model;
Also, try to create a brandnew project and pick the template:
Templates->Visual C#->AWS->App Services->Amazon Elastic Transcoder Sample
See if that installs and runs correctly - it does for me on VS2012 with .net 4.5
I may be reposting but I cannot find solution of this.
I create a C# Comvisible Class. This is the following class:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
namespace COMTrial
{
[Guid("2B71BC1B-16F5-4A0D-A015-CAE658A10B07")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface IMyExample
{
string GetData();
}
[ClassInterface(ClassInterfaceType.AutoDual), ComSourceInterfaces(typeof(IMyExample))]
[Guid("2B71BC1B-16F5-4A0D-A015-CAE658A01B07")]
[ComVisible(true)]
public class Class1
{
public Class1()
{
}
[ComVisible(true)]
public string GetData()
{
return "Vikas";
}
}
}
Then I checked Register for Interop option and even made the complete assembly visible and compile the project and solution.
Then I went to excel and wrote this code:
Dim a as Object
set a = CreateObject("COMTrial.Class1")
It says,
ActiveX cannot create an object.
The only reason I think of is that I am running Office 2010 64 bit with Windows 7 64 bit.
Then I checked Register for Interop option
That will only register your assembly for 32-bit processes. Since this is the 64-bit version of Office, you will need to run Regasm.exe by hand. Do so from the Visual Studio Command Prompt, started with "Run as administrator". Be sure to use the 64-bit version of Regasm.exe, for .NET 4 it is located by default in C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Note the 64. Use the /tlb and /codebase options to match the IDE's behavior.
Another improvement is to use the [ProgId] attribute explicitly so you don't have to guess at the name and won't have a problem if the project name is not "COMTrial".
When deploying and registering a .Net Excel.dll on another computer, I get an error Can't add a reference to the specified file when attempting to add reference to DLL in VBA editor.
I have created the Excel.dll in C# in Visual Studio that runs fine on my machine with Windows 7 and Office 2010. No problem adding reference to the dll in Excel VBA editor on my computer. My problem is deploying on another machine which is running Vista and Excel 2007. I copied dll to this computer and used regasm to register the dll.
Can anyone point me in the right direction? Here is code and regasm:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe excelDll.dll
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestDll
{
[ClassInterface(ClassInterfaceType.AutoDual)]
public class Test
{
public string HelloWorld
{
get
{
return "Hello World";
}
}
public void sayGoodbye1()
{
MessageBox.Show("Say Goodbye");
}
public string sayGoodbye2()
{
return "Say Goodbye";
}
}
}
You need to register the type library for excel to see your dll in References.
i.e. regasm.exe excelDll.dll /tlb:excelDll.tlb
Mark.
I recently encountered and managed to solve exactly this problem - though I can't claim to understand exactly why my solution worked.
Both my systems are running Windows 7 x64. One has Excel 2010, the other Excel 2007.
All the C# assemblies are set to "Platform Target: Any CPU". The primary assembly is set to "Register for COM Interop". The whole thing is installed using an MSI created by a Visual Studio Installer project.
I found that if I set the Visual Studio Installer project "Target Platform" to "x64", then it works in Excel 2010, but not in Excel 2007. Conversely, if I set the Visual Studio Installer project "Target Platform" to "x86", it works in Excel 2007 but not in Excel 2010.
Sadly, I'm not in a position to test both Excel versions on the same machine at the same time - but at least this might get it working for you!