none
Why would a COM-visible-Assembly work on any machine but not on any machine in my company? RRS feed

  • Question

  • Hello,

    I am stuck for more than one year now with this problem.
    I already submitted it in another thread .
    But I would like to ask again from another point of view: "Why ok on one machine and not on another?".

    I created a very short (C#) COM-visible-Assembly (called netcom2vba) that reproduces the problem.
    Basically, this code works  in Excel on any machine in my company or outside my company:

    Function test(str As String)
        Set obj = New netcom2vba.netcom2vba
        test = obj.myLen(str)
    End Function

    While this code doesn't work on machines in my company (unless it is a developer machine),
    yet it works anywhere else:

    Function test(str)
        Set obj = New netcom2vba.netcom2vba
        test = obj.myLen(str)
    End Function

    (A developer machine is just a normal machine where Visual Studio has been installed)

    When it doesn't work, I get this message when debugging in VBA:

     430 
    Class does not support Automation or does not support expected interface
     1000430 
    C:\PROGRA~2\COMMON~1\MICROS~1\VBA\VBA7\1033\VbLR6.chm
    VBAProject

    This indicates that the object is created properly (which I checked) but that the method cannot be reached properly.
    Yet on most machines of the world it would work, but not in my company.

    Understanding and solving this problem at the root would be helpful.
    Otherwise, I could modify the assembly to make it work when the argument is not a String (but a Range).
    But that would really not be my preferred solution.

    Thanks for any suggestion!

    Michel

    tiny test code: here



    • Edited by Lalbatros Tuesday, September 1, 2015 8:52 AM
    Tuesday, September 1, 2015 8:50 AM

Answers

All replies

  • I actually spoke on your other thread but to be honest I am pretty confused.

    You start by saying you created an assembly to repro it.

    Then said this works

    Function test(str As String)
       
    Set obj = New netcom2vba.netcom2vba
        test
    = obj.myLen(str)
    End Function

    All the time, meaning you actually create and then use it in Excel etc (both inside and outside your company)?

    Then you say this doesn't work

    Function test(str)
       
    Set obj = New netcom2vba.netcom2vba
        test
    = obj.myLen(str)
    End Function

    But why would you use create any function that takes a parameter in that doesn't specify the type? And if the other code works, why would you change it?

    And you are certain that THIS code works on your brothers, neighbors, cousins, dogs laptop... but won't work on ANY system in your network, side from developers? How do you know this?

    Ok aside from that (wow my fonts are purple lol)

    1. What version of Office is everyone using

    2. If you are installing VSTF (xxxxx) you are getting files that your other folks won't get

    3. Do you update your non-dev boxes to the latest versions of .NET framework?

    4. Any SDK's that you have on your dev machines (office etc) that you don't have on others?

    5. Where are the tlb files at?

    6. What version of VBA do you have on your dev machines compared to what is on your non-dev machines

    7. What OS version are you guys using?

    Clearly the issue here is that the interface itself is NOT seen outside, because of a dependency or version of a dependency (such as VBA) that your dev machines have, that your others don't.

    Now aside from that, that also means somehow, whatever updates external people are using, your people (whom are not devs) aren't.

    8. How are you registering the component on your machines. In the dev machines are you merely "compiling it", because that would be cheating :-). On your non-dev machines are you regsvr32'ing it or what? Is it in the GAC properly? Are they interfaces public bla bla bla bla  :-)

    Tuesday, September 1, 2015 10:29 PM
  • But why would you use create any function that takes a parameter in that doesn't specify the type? And if the other code works, why would you change it?
    -The method(s) might be called sometimes with a String and at other times with an Excel Range (Cell).
    But the main reason is that this code is a translation from a Java (J++) package that I wrote 15 years ago. It worked very well and I want to replace it by a fully compatible C# assembly. (win 7 doesn't allow the MS java virtual machine anymore)
    I also don't want to modify the hundreds of Excel workbooks that are based on this J++  package.
    I am very fortunate that I used late-binding in these workbooks. In this way, the J++  package could be replaced by a C# assembly without any other change (the version can even be chosen by the user by specifying an assembly name). This is how it works on many test machines but not any user at work!

    And you are certain that THIS code works on your brothers, neighbors, cousins, dogs laptop... but won't work on ANY system in your network, side from developers? How do you know this?
    -This was not an urgent problem, and I had more than one year to take any opportunity to test it.
    It worked everywhere I could test it, but never by my colleagues.
    The IT guys thought that was a user's right problem, but it is not.
    I asked for a standard PC with additional admin rights, and I got the same result: it doen't work.
    Yet everywhere else it works.

    1. What version of Office is everyone using
    -Office 2010 32bits for everybody. Since a few months I am now using both 2013 and 2010 on my work machine and 2013 on my personal machine. But the problem was already clear before that.
    Just installed SP2 on user's box, but no improvement.

    2. If you are installing VSTF (xxxxx) you are getting files that your other folks won't get
    -I don't use VSTF. I am a stand-apart developer. I do physical process simulation while the rest of the IT is business-oriented (SAP and the like).

    3. Do you update your non-dev boxes to the latest versions of .NET framework?
    -That's done in a very systematic way. (thousands of PCs)

    4. Any SDK's that you have on your dev machines (office etc) that you don't have on others?
    -Anything that come with a standard VS setup.
    On my work machine I have several versions of VS and maybe some SDK.
    On my private machine I only have a clean VS2013 setup.
    Tests build on my work machine or on my presonal machine give exactly the same results.

    5. Where are the tlb files at?
    -The setup program copies the primary outputs including the tlb to the Application Foler. I am using a Visual Studio Installer project to do that. 
    I don't do anthing else. I don't think anything else is needed since it works generally, and since the setup effectively populates the registry with all that might be needed to use the assembly. 

    6. What version of VBA do you have on your dev machines compared to what is on your non-dev machines
    -On my test user machine: version 7.0 . (retail 1628)
    On my dev machine: version 7.0 (retail 1637)
    On my private machine: version 7.1 (retail 1049)

    7. What OS version are you guys using?
    -Win 7 64 bits.
    Win 8.1 on my private machine.

    Clearly the issue here is that the interface itself is NOT seen outside, because of a dependency or version of a dependency (such as VBA) that your dev machines have, that your others don't.
    -Yes! 
    I don't understand precisely how this all works, but I spent quite sometime on the web to figure out where something could be missing.
    Eventually I spent more time on this "marshalling" stuff, but could not really visualise it.
    Is this "marshal" really working on my boxes? And when could I see it at work? 
    Is he missing on the machines of my collegues?

    Now aside from that, that also means somehow, whatever updates external people are using, your people (whom are not devs) aren't.
    -You really give me some hopes!
    I re-installed Excel yesterday in the hope to refresh it. But it didn't work.
    Indeed retail version of VBA is lower on my test user machine than on my dev box.
    Maybe VBA was not changed since it is shared with other Office applications. 
    Maybe I do a full re-install later to check.

    8. How are you registering the component on your machines. In the dev machines are you merely "compiling it", because that would be cheating :-). On your non-dev machines are you regsvr32'ing it or what? Is it in the GAC properly? Are they interfaces public bla bla bla bla  :-)
    -On the dev box, I compile and "Register for COM interop".
    I did a test project on my private machine and installed it on my work dev machine: it works even though VBA version is lower on my work machine!
    On user's boxes I run the setup program. It populates the registry in the same way when it work or when it doesn't.
    Nothing is installed in the GAC, everything ,goes to a program files folder.


    Thanks Anokneemous!


    • Edited by Lalbatros Wednesday, September 2, 2015 4:36 PM
    Wednesday, September 2, 2015 3:17 PM
  • I'm still thinking on this, thank you for taking the time to answer.

    If I had a copy of the items I would debug them for you on one of my machines. But let me ask something.

    Is there any chance, you could ask IT to build a machine out, using whatever process they use, so that you end up with a machine that does NOT work.

    Personally I would do a few things here but simply.

    If you insure it doesn't work. Now install your VS (like you would on a developers machine).

    1. Don't try to "compile and run it" just install VS.

    2. Then run your install package

    If this works, then you know its VS installation doing something

    If not then go to Step 3

    3. Compile from VS and have it register it for you (you could even try having the USER be logged in and not your dev account when you compile it)

    If this works then you know it's a problem with the registration process. You have to register that file somewhere on the machine so it should be there. It will be gacc'd when you registered it via VS compile.

    I am wondering if it's a permissions issue. Maybe on your dev machines it works because you are registering as the user whom is running VS, and then when you test, WHO are you logged in as? It is possible for something to be registered and not accessible and or in a "folder" but not accessible (permissions wise) and yet you can technically "see it" but not access the methods.

    You may need to do combinations like.. Have a user who is on your network but NOT a developer to log into a developer box.. and see if it works. This might work and yet still be a permissions problem since your developer registered as a COM object (meaning regsvr32'd it for yourself).

    Sometimes the errors you get will not clearly be "security" failures but they might actually be.

    So couple more things

    1. On a developers machine are you also an admin?

    2. Are users actually admins of your own local machines or just "users" (versus maybe an admin Dev)

    Try also to have a Developer log into a machine where it doesn't work.. and then try it, if you are a global network admin and it works for you and not them, again could point to security

    Actually debugging this (to me) with filemon / procmon should tell you exactly WHY you cannot see the function, because when it tries to access it, you should see "authentication failures" or "missing dependencies" etc. That's better than using the actual HANG / CRASH dumps I mentioned.

    lastly you mentioned you are using 64 bit OS, but what is your "VS Compile" outputting? 32 BIT or 64 BIT? Do you have 64 bit components but 32 BIT office? Sorry caps lol.

    If it's not permissions, then possibly you are merely having a marshalling issue, in which case with VS installed you are getting both 32 and 64 bit libraries you wouldn't get on a 32 bit Office + 64 bit os necessarily

    • Edited by Anokneemous Wednesday, September 2, 2015 7:49 PM more details
    Wednesday, September 2, 2015 7:46 PM
  • If I had a copy of the items I would debug them for you on one of my machines.

    This evening I created a tiny project on my personal Asus box. My aim was to install it on the DEV box as well as on the USER box. In this way VS is not involved on any of these two machine.

    As usual, it work on the DEV box and not on the USER box!

    I made a copy of that on OneDrive, here.

    Is there any chance, you could ask IT to build a machine out, using whatever process they use, so that you end up with a machine that does NOT work.

    I did that. This is what I call my User box. I received that just the purpose of testing (after one year idle). I asked in addition to have admin rights on that machine. The tests never work on this machine.

    That showed that giving admin rights was not a solution to the problem.

    (I also tested that it works if the types are correct, so the “marshaling” doesn’t work)

    Now install your VS (like you would on a developers machine).

    Before doing that I would like to try other things.

    The reason is that maybe I won’t be able to reverse this operation.

    In that case I will have to ask the IT to re-install the USER box from their standard image. I cannot be sure about how long I will have to wait!

    I will think about it anyway. Sleep may help me to decide.

    It will be gacc'd when you registered it via VS compile.

    The assembly never goes to the GAC, neither when compiling, nor when installing.

    When compiling, the registry points to the debug folder where the dll was created.

    When installing, it points to the program file folder where the primary outputs have been copied.

    I am wondering if it's a permissions issue.

    Indeed. But that’s not where I am the most competent. I browsed also the policies and did not see anything that could be obviously related to my problem.

    For security, I have no idea what I should look for.

    WHO are you logged in as?

    I made all my tests as administrator.

    I even once launched Excel as administrator. No result.

    Actually debugging this (to me) with filemon / procmon should tell you exactly WHY you cannot see the function …

    I started using procmon. On two screens side by side, the DEV box where it works and the USER box where it fails.

    I analyzed only the early binding test excel/vba.

    I did not analyze till the execution of the VBA test, lack of time.

    I only analyzed what happens when the file is opened, some 5000 events!

    I found something noticeable. On the USER machine, there a series of steps where it looks like excel looks for its way to the type library.

    This is probably because of the early binding: Excel looks for the references of the VBA project and resolves them.

    On the DEV machine, it looks like this process is performed twice!

    I could not see yet a significant differences between these two repetitions.

    I will look patiently tomorrow at work, if I find enough time.

    Procmon looks promising but takes time. (specially experimenting to learn)

    “VS Compile" outputting? 32 BIT or 64 BIT? Do you have 64 bit components but 32 BIT office?

    Win is 64 bits, Office is 32 bits. But that’s true for all boxes I had tried.

    Compilation targets “Any CPU. Does that mean MSIL code?

    If it's not permissions, then possibly you are merely having a marshalling issue …

    How could a marshalling issue be solved?

    Would there be some package to be installed? I have almost no understanding of marshalling.

    I only can’t see how type conversion could proceed without. I know of nothing else.

    But why do the test work on so many machines and not at work?

    Missing a marshal there?

    Thanks a lot for the hopes!


    • Edited by Lalbatros Wednesday, September 2, 2015 8:51 PM
    Wednesday, September 2, 2015 8:50 PM
  • I'm checking our your onedrive right now

    If you want to share your output (sorry if its there and I didn't look yet) for your procmon output.

    The filemon is really good to use too though (I know it's called filemon but it doesn't merely look at file operations lol)

    Sorry I just realized it's replaced with Process Monitor v3.2

    Yeap agree it spams a lot, but this will help I believe more than anything.

    Marshalling is usually a problem when a missing dependency or "version" of something has changed in which case the way in which marshalling is done, and or the object type is no longer visible / valid etc. So technically you would solve it via some installation / update or something. Now finding the "what" is what process monitor should help you do.

    I realize it's a pain... but it will get you somewhere.

    BTW, if you take a Back of your system or at least do a restore point before installing anything you can get back to where you were.

    Any chance those folks can provide you a VM?

    Only reason I ask.. is if that's the only way to debug, and you can share that, I'd be happy to help there. And you would be able to get back much faster.

    Cheers,

    Wednesday, September 2, 2015 9:32 PM
  • Oh and are you signing these?
    Wednesday, September 2, 2015 9:33 PM
  • Ok I tested your little sample and it worked fine after I ran the install of your component.

    Another option you can also look at is, you should run Process Monitor and debug the actual installation package as well....

    See if there is something that fails that you just don't know about.

    Also, I am wondering if somehow.. the user doesn't have privs to the folder you are running it from (on the users box). You said you are using Windows 8, but they are using Windows 7.

    So the elevation privs changes etc.. may not be in there yet.

    Unfortunately I still think its either privs or marshalling, but I will need to look at the Process Monitor log files to see if I can pinpoint something.

    Dang I hate things that I can't repro, if I could it would make it way easier for me.

    Let me try on another system that is just a dummy VM with Office

    Wednesday, September 2, 2015 10:04 PM
  • If you want to share your output (sorry if its there and I didn't look yet) for your procmon output.
    I will do that soon. I just wanted to have something clear before sharing.
    It is the first time I will really use procmon.

    Any chance those folks can provide you a VM?
    They are crazy about security.
    They disabled networks on the User box they provided me.
    I was supposed to communicate with memory sticks.
    That proved impossible of course, specially when I tested a full re-install of Office.

    It is clear that it would be better if that could be reproduced outside.
    But I could always try your suggestions.

    full re-install of Office
    I tried it and it didn't change anything.
    I thought that I could try installing Office 2013, or Office 365.
    Again, I would give that a good (reasonable) chance of working.
    Before I go to such extremes, I will us procmon for some time.

    Thanks again for the hopes !!!

    Thursday, September 3, 2015 6:04 AM
  • Oh and are you signing these?
    No I don't sign it.
    Previously I tried signing in other similar tiny tests, without more success.
    • Edited by Lalbatros Thursday, September 3, 2015 6:22 AM
    Thursday, September 3, 2015 6:07 AM
  • Ok I tested your little sample and it worked fine after I ran the install of your component.
    No surprise.
    It is clearly a problem related to the configuration at work. 
    It confirms my opinion that we should all bring our own devices at work.

    run Process Monitor and debug the actual installation package as well....
    That's an excellent suggestion!
    I would guess for no difference, but that's precisely where a difference could make the difference!

    user doesn't have privs to the folder you are running it from
    In the tests I do, I always have admin rights and I have all access to the Program Folder where the test installs.
    Btw, it goes into the folder  
     "C:\Program Files (x86)\Default Company Name",  which is not a very clever name.

    You said you are using Windows 8, but they are using Windows 7.
    It is only on my private box (Asus).
    Yesterday it was the first time I compiled a test on my Asus.
    Before I always used Windows 7 machine, with the same results.
    The reason why I compiled on still another machine was to compare what happens on DEV box and USER box when the test is installed in the same way on these machines. As expected it worked on DEV but not on USER.
    I will dig into that with procmon.


    • Edited by Lalbatros Thursday, September 3, 2015 6:21 AM
    Thursday, September 3, 2015 6:21 AM
  • Hello Anokneemous,

    You will find here a new version of the tiny test.
    I change a little bit the early binding excel file. The name of the assembly was not correct.

    I also added a folder where the result of ProcMon are available.
    There are eight file depending on:

    which machine was tested: DEV or USER
    which excel file was tested: EARLY binding or LATE binding
    which test was made: OPEN the file, or CALC the file (by entering a new string.

    Thursday, September 3, 2015 7:16 AM
  • I just realized that at work we are all using  Office 2010 Pro Plus.
    Would there be something odd with the Pro or with the Plus?
    As I can't find any explanation, I suspect anything.

    I made also some tests with the assembly binding viewing tool (FUSLOGVW.exe)
    I did not see evidences of binding problems that would occur specifically on user machines.

    Thursday, September 3, 2015 8:03 PM
  • Apologies I've been busy and didn't get a chance to look at this.

    Hmmm I am not aware of specific problems you would have, however that doesn't mean there isn't a difference.

    Ok... another silly question.

    Is there any chance of getting a user machine that does NOT have your office installed.. Any chance you guys have an MSDN account? One that you could install an MSDN version of Office on that machine?

    See if the problem goes away and if so, then you might have found the problem. It would take more debugging at that point, but I've never used Pro Plus..

    The fact that you can see the object clearly demonstrates its in the registry... but can you look in the registry and validate that it looks the same as what it looks like on a machine that is working?

    Validate that the GUIDS etc are the same.

    Because in COM it's the Virtual Table that would be the problem. So you could technically write could that could traverse the virtual table of the COM object. See if it matches what's in the registry or if there is anything else weird .

    Make sure on both (good and bad) working machines the are identical.

    Saturday, September 5, 2015 2:19 AM
  • Hello Anokneemous,

    I uninstalled Office2010 Pro Plus from my  test user box,
    and I then installed Office2010 Pro from an old personal purchase (probably downloaded from MSDN).

    The problem remains untouched.

    I then did the reverse operation, which also left the problem as before.

    This is at least a clear fact now.

    I consider now to install Visual Studio or some redistributables of Visual Studio.
    I observed that some redistributables are already installed on all boxes at work.
    It is mainly related the C++, and I saw also that SAP has an entry called "Microsoft redistributable runtime DLLs VS2005 SO1 (x86)" and the same for VS2008.

    I compared GUIDs from VBA references on both bad and good machines, and they are the same.
    I could do more using the process monitor, but that needs more time and a clean experiment, maybe today ...

    Have a nice day,

    Michel

    Sunday, September 6, 2015 7:40 AM
  • Hello,

    I played quite a lot with procmon and found some precise problem with loading dlls.
    I started another thread where I ask a more precise question.

    Thanks,

    Michel

    Wednesday, September 9, 2015 9:12 PM
  • Problem is related to the regional settings.
    Some regional settings do not work.
    Probably installing the ad-hoc language pack would solve the problem.
    Problem is: some regional settings are not associated with a language pack (like  French (Belgium)).
    Question remains: Why should the functioning of a COM-visible Assembly  depend on the Regional Settings and on how Excel reacts to these settings?
    Thursday, September 24, 2015 6:34 AM
  • Hi Lalbatros,

    >> Why should the functioning of a COM-visible Assembly  depend on the Regional Settings and on how Excel reacts to these settings?

    It seems your issue is similar with the thread below, right? If it is, I suggest you try the last reply of mine.
    Reference: https://social.msdn.microsoft.com/Forums/office/en-US/59c2c9ad-1b5c-4eba-a1ba-8de3d91945a3/class-does-not-support-automation-in-some-regional-settings-but-not-in-others-how-can-that?forum=exceldev

    If you have any issue about this, please feel free to let me know.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    • Marked as answer by Lalbatros Friday, October 9, 2015 6:58 AM
    Thursday, October 8, 2015 6:03 AM
  • Thanks Edward.

    Your answer in the other thread solves the issue.

    Michel

    Friday, October 9, 2015 6:59 AM