Resolved System.IO.FileNotFoundException

[FerroCoder]

There is a lot of information about this exception, but I haven't been able to find a solution.

Background: I am a long-time C++/MFC developer, relatively new to C#/.NET. I am in the very early stages of redeveloping a very large (2+ MLines) C++/MFC program under C#/.NET 6.0. The prototype has been going well until I recently added a namespace/class. Now, on program startup I get the error of the first figure:

CPauseClass, CDCBiasClass and CHysteresisClass are wrapper classes around CPause, CDCBias, and CHysteresis classes defined in namespaces IPause, IDCBias and IHysteresis, respectively. The class hierarchy is shown in the second figure:

0

The wrapper classes are partially defined as:

class CPauseClass
{

    CPause m_pPause = new CPause(  true );
    CTask m_tMyTask = null;

...
}  // CPauseClass

class CDCBiasClass
{

    CDCBias m_dcDCBias= new CDCBias(  true );
    CTask m_tMyTask = null;

...
}  // CDCBiasClass

class CHysteresisClass

    CHysteresis m_hHysteresis = new CHysteresis(  true );
    CTask m_tMyTask = null;

...
}  // CHysteresisClass

(Yeah, I'm carrying MFC habits into C#.)

The exception is thrown when CHysteresisClass includes the declaration for m_pHysteresis, even though the exception itself appears in the declaration of m_pMyHysteresis as in the first figure.

Clearly a file associated with IMeasurement is not being found. No exception is thrown for ITask or IHardware. I can find no substantive difference in the IHardware and IMeasurement project properties. Both projects output equivalent files. Reference to IHardware is not throwing an exception.

Project dependencies are properly set.

Questions:

- Is there a way to trap this exception? I cannot use a try/catch block since the exception is occurring on member declaration, not in procedural code.
- Is there a way to determine which file is not being found without trapping the exception? I have copied IMeasurement.dll to the program executable folder. This didn't help
- C# does not seem to offer path settings for included dependencies. Is there a way to expand the search path that the executable is using?
- Is a null PublicKeyToken a problem?
- Can anyone offer any other suggestions?

Thanks in advance for any help that you can offer.

FC

 

[Skydiver]

As a quick aside, the C prefix already stands "class" in MFC Hungarian, so there is really no need to name something "CFooClass".

 

[Skydiver]

In general, if you setup your solution so that your "IMeasurement" project that builds the "IMeasurement.dll" assembly is a sibling project of this current project that you are trying to compile, then Visual Studio will figure out the correct order of building things.

But if you insist on having the just the raw "IMeasurement.dll" assembly, then you would use the "Browse" blade of the "Add Reference" dialog box:

 

[Skydiver]

- C# does not seem to offer path settings for included dependencies. Is there a way to expand the search path that the executable is using?

No C# does not since C# is a language, not a compiler. But the C# compiler lets you use the /LIB command line flag, and the Visual Studio has this under Project Settings to let you tell the compiler where to look for assemblies that you reference:

As for expanding the search path that the executable is using, you can play some games with your app.config file to tell the framework where to look for assemblies at runtime. That won't have any impact on compile time, though. But again, this isn't a function of the C# language. This is a function of the .NET Framework.

 

[FerroCoder]

Skydiver,

Thanks for this reply. It gives me some things to try. I think that you are correct that I should refactor my project organization so that all projects are sibling projects of the program project. This will take me some time and I will be out until Monday, but I will give both these solutions a try.

I will mark this resolved when I am successful.

Thanks again,

FC

 

[cjard]

Yeah, I'm carrying MFC habits into C#

*Shudder*

 

[FerroCoder]

Skydiver,

Thanks, again. After adding the direct reference, things started working again. Just a few comments:

First, I apologize for lazy language. I referred to "C#" when I meant the Visual C# environment.

I also misread "Sibling" as "Child". I thought I would create the class hierarchy as sub-projects under the main program project, IVision6. However, these are already sibling projects, as in the first image here. I cannot seem to create projects under projects - only classes. This would be untenable. This project will have thousands of classes. They will need to be grouped into independent projects.

Arranging projects as siblings, alone, resulted in the runtime error. It took the explicit reference to get this to run. I did not exactly see the tools that you referred to, the browse option worked for me.

Thanks again. This was a hard-stop problem and it took your help and experience to get beyond it.

FC

 

[Skydiver]

Why a DLL per class? Seems like an extreme form of planning to service a code base by isolating each class in it's own project/assembly. In my opinion: YAGNI.

 

[FerroCoder]

Not a DLL per class. The overall project consists of the main program and about 140 semi-independent agents - here, Pause, DC Bias, Hysteresis for the sake of the prototype. All agents are derived from one of the three ancestor classes as in the second image of the original post. The main project and each agent will consist of a number of classes, especially since dialogs - sometimes many - are associated with each agent. A number of support projects also service the agents and not necessarily the main project. The original C++ project consisted of about 200 total projects. Separate projects that originally serviced the main program now look as though they will serve better as classes under the main program project, reducing the number of DLLs.

Note, that the original project depended on the agents as DLLs, with particular file extensions being searched and loaded by the program at startup. The main program had little or no knowledge of the nature of any given agent. I haven't yet determined how I'm going to handle that in C#. Right now I'm considering a Task Bank (agents are known as Tasks in Vision) that will be aware of every available agent.

Since I have developed this over twenty-five years, there is a lot of inefficiency and dead-weight that I am working to design out. I am also looking to incorporate any C#/.NET philosophy that differs from C++/MFC norms. It is very early in the prototype and I am as busy learning the nuances of C# as I am working on the development. They are not exclusive.

Thanks for spending some time with me on this. I hope to get to the point of being a contributor soon.

FC

 

[Skydiver]

Sounds like a prime candidate of taking advantage of the strategy and bridge design patterns.

 

[Skydiver]

The main program had little or no knowledge of the nature of any given agent. I haven't yet determined how I'm going to handle that in C#. Right now I'm considering a Task Bank (agents are known as Tasks in Vision) that will be aware of every available agent.

Microsoft offers up MEF as their solution for this type of plug-in model, but in some ways is it also over engineered. It maybe worth reading about what MEF has to offer, and then decide for yourself if you want to use MEF, or roll your own lighter weight version.

 

[cjard]

A lighter weight version could look like defining interfaces that plugins comply with, and have the main app load DLLs, reflectively examining their contents for implementations of known interfaces. When the main app has work it wants a plug-in to do it loops them al, asking if any are interested in doing the work it is offering (the method for which is part of the interface too). The main app this never really knows anything about its plugins, it's just a container for them and a work arranger

 

[FerroCoder]

Thanks for the continued suggestions. This has given me a lot to think about and study up on. And this is the right time for it. Most of the original design was completed in the first two years (late 90s). Everything since then had been large-scale expansion and maintenance. Any redesign in the original technology became impractical, especially since I have been, for the most part, the sole developer, documenter, trainer and customer support agent. Let me spend some time with these ideas and I may get back to you.

Thanks again,

FC