Jump to content
  • Advertisement
Sign in to follow this  
nsto119

[.net] Is referencing an .exe a bad idea/not recommended?

This topic is 4406 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I can't think of a reason why it would be... seems to me that an assembly is an assembly, but my gut is telling me that I'd be ridiculed and laughed at and poked with sticks until I bruised slightly if I did it. Also, say I have the same exact interface defined in two different assemblies. If I instantiate an object that implements the interface from one assembly in the other, why does trying to cast it back to the interface throw an InvalidCastException? Sorry if that's confusing.

Share this post


Link to post
Share on other sites
Advertisement
Because they aren't the same class. The compiler doesn't care that you copy pasted the same code and compiled it in two seperate places - unless it does a byte per byte comparison it won't know that they are "the same" class (and even then, two compilers could easily produce different binaries). You need to compile it in one place, then reference that assembly in the other places you want to use it.

Share this post


Link to post
Share on other sites
Just to be silly once, when I learned that .NET exes are just the same as dll assemblies, I made ALL my libraries exes, and had running them simply open a form displaying the version information for each. I wanted to try having it run the test-functions as well, but it wasn't worth the effort :)

It would probably make your users a little scared though. The .exe distinction is helpfull to your users for finding what they should click / shortcut to.

Share this post


Link to post
Share on other sites
I was making an extension to an existing .NET application and, because I was too lazy to download the source so that I could work with it directly, I just referenced the executable and inherited its members. It worked, until I tried it in .NET 1.1 . The work I did eventually made it into the core application's source anyway....

Share this post


Link to post
Share on other sites
Quote:
Original post by Xai
It would probably make your users a little scared though. The .exe distinction is helpfull to your users for finding what they should click / shortcut to.


Well, that wouldn't really be an issue I think. The idea was to have an exe that loaded assemblies at runtime for a plug-in-like system. I'd be instantiating objects from the DLL that implemented an interface (an input device interface) that was defined in the .exe. But, if referencing an .exe is a bad idea, I'll just have to had another dll to my project that contains all the interfaces that both the .exe and DLLs need to know about.


Another question: Is it possible to get both the shortcut path AND dereferenced path with an OpenFileDialog?

I'm writing a program that keeps track of how much time you spend in each program. So, I have a dialog that allows you to choose an .exe that the program would track. I'd like the user to be able to select shortcuts, because it's possible to extract the actual name of the program from a shortcut, where as if I dereference the shortcut, the only thing I can get is the .exe's name, which isn't always the name of the program.

For example, from the shortcut C:\Desktop\Visual Studio 2005 Standard.lnk, it's possible to extract "Visual Studio Standard 2005", but I can't extract the icon for the pretty display with Icon.ExtractAssociatedIcon( string );. Where as if I dereference the link, I just get something like C:\Program Files\Microsoft\devenv.exe. "devenv" is the name of the process, which I need, but it's not the name of the program and doesn't look familiar or nice in the list of programs.

Share this post


Link to post
Share on other sites
Quote:
Original post by nsto119
Quote:
Original post by Xai
It would probably make your users a little scared though. The .exe distinction is helpfull to your users for finding what they should click / shortcut to.


Well, that wouldn't really be an issue I think. The idea was to have an exe that loaded assemblies at runtime for a plug-in-like system. I'd be instantiating objects from the DLL that implemented an interface (an input device interface) that was defined in the .exe. But, if referencing an .exe is a bad idea, I'll just have to had another dll to my project that contains all the interfaces that both the .exe and DLLs need to know about.


FYI: Nasa's World Wind had the interface for thier plugins defined in the exe. They allowed the use of uncompiled .NET code, and compiled dll's for plugins. If I remember correctly, with the compiled DLL route, Visual Studio 2003 would not allow you to make a reference to an EXE by default (I'm assuming this is true with 2005 also). Instead you had to manually edit the project file in a text editor and add the <Reference Include> to your executable manually. After which you could open your library project and it would show the exe as a reference.

- Bill

Share this post


Link to post
Share on other sites
Quote:
Original post by Billr17
If I remember correctly, with the compiled DLL route, Visual Studio 2003 would not allow you to make a reference to an EXE by default (I'm assuming this is true with 2005 also).

No, 2005 allows you to reference both exes and exe projects. I have lots of times made a library an exe for the purposes of easier testing, and then forgot about it later.

Share this post


Link to post
Share on other sites
Quote:
Original post by Arild Fines
No, 2005 allows you to reference both exes and exe projects. I have lots of times made a library an exe for the purposes of easier testing, and then forgot about it later.


Good to know, thanks.

Share this post


Link to post
Share on other sites
For plugin systems I certainly don't see anything wrong with the plugins referencing the EXE they are 'plugging in' to. I've built a couple of applications extensible through plugins and I do it that way.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!