Help! My project list a file in the Dependencies that shouldn't be there

[george seifert]

My project has a file in the Dependencies section and I can't figure out why it's still there. I converted this project over from a similar project that did use that file (a dll). Now I'm trying to get it to use a different dll. The problem is in just one VI (I right clicked on the dll to find out why it's there and it directed me to the VI where it was). I replaced the references to the old dll with the new one countless times and even replaced the actual nodes that call the dll, but the dll won't get out of the Dependencies section. I've even rebooted the PC to make sure all references are gone. Is there a way to pinpoint where a dll is actually used in a VI? The weird thing is the VI is not broken even when I change the name of the old dll and the project gives the warning that it has been deleted, renamed or moved. It just won't let go of that old dll.

George

[Jon Kokott]

I would try dispatching the .dll by wiring the path.

If that doesn't work, try searching for diagram disable structures.

Anything in a diagram disable will not be compiled and will not be shown in the callers list, but still will be listed as a dependency even though you are not really using it. I've had this kind of conflict several times when using other people's code.

~Jon

[george seifert]

I would try dispatching the .dll by wiring the path.

If that doesn't work, try searching for diagram disable structures...

~Jon

I can't wire in a path. I'm using constructor nodes (these are .NET calls) and there's no way to wire in a path that I can see. I also have a .net constant tied to a "To More Specific Class" VI.

No disable structures either.

Maybe it's the callback VI that also used to reference the dll? I wonder if I'll have to destroy that and start fresh.

George

[Jon Kokott]

I'm really not familiar with the .net framework, but it seems that you are using windows to dispatch the .dll. Have you tried registering your new .dll using regsvr32 (http://ss64.com/nt/regsvr32.html)

otherwise you can check out the attached tutorial on the windows registry.

~Jon

[Jon Kokott]

I'm really not familiar with the .net framework, but it seems that you are using windows to dispatch the .dll. Have you tried registering your new .dll using regsvr32 (http://ss64.com/nt/regsvr32.html)

otherwise you can check out the attached tutorial on the windows registry.

~Jon

I forgot I cant attach files at work. there are tutorials online for how to use the windows registry, just be careful when manipulating these files.

~Jon

[george seifert]

I'm really not familiar with the .net framework, but it seems that you are using windows to dispatch the .dll. Have you tried registering your new .dll using regsvr32 (http://ss64.com/nt/regsvr32.html)

otherwise you can check out the attached tutorial on the windows registry.

~Jon

The new dll works in multiple other places in my code so I don't think it's a registration problem. It's just that for some reason this one VI has a hidden reference to that old dll.

George

[Daklu]

You don't use regsvr32 to register .Net assemblies. If you want to put an assembly in the GAC you use either gacutil.exe or Windows Installer, but an assembly doesn't necessarily need to go in the GAC.

George,

What are the names, version numbers, and locations of the old dll and the new dll? If the names and versions are the same but with different paths, it could be that the Fusion engine (the MS component that finds the right assembly) is finding the old dll before the new one.

[george seifert]

George,

What are the names, version numbers, and locations of the old dll and the new dll? If the names and versions are the same but with different paths, it could be that the Fusion engine (the MS component that finds the right assembly) is finding the old dll before the new one.

The name and location of the old and new dll are different. Is there anyway to see exactly where in a VI a dll is being referenced?

George

[Daklu]

Is there anyway to see exactly where in a VI a dll is being referenced?

AFAIK while in the dev environment .Net assemblies are only referenced in the constructor node. Do you have any .Net reference controls, indicators, or constants on that vi? That could hold the assembly reference too.

[george seifert]

AFAIK while in the dev environment .Net assemblies are only referenced in the constructor node. Do you have any .Net reference controls, indicators, or constants on that vi? That could hold the assembly reference too.

Yep, there are three of them. I've replaced all of those nodes. Too bad there's not a way to search for that dll like you can with the Call Library Function Node.

George

[Daklu]

Yep, there are three of them. I've replaced all of those nodes.

Well, if you've replaced all the constructor nodes, controls, and indicators in all your vis and it's still not going away, I don't know what to tell you. I'm running out of good ideas.

I assume you've checked to make sure you don't have anythink hidden off screen or behind the edge of a frame?

Something else to try is deleting all the constructor nodes, controls, and indicators and seeing if it's still there. If it is see if it still points you to the same vi.

Another thing you can try is to make a backup of the guilty vi then go back and start deleting stuff and saving until you find the part that is causing the trouble. I vaguely remember having a similar problem, though I'm not sure it was related to dlls. I ended up deleting all the vi contents and recreating them.