A little bug in .Net samples

A little bug in .Net samples


It seems that original avisnet.dll damaged (and shouldnt be renamed). When I tried to build C# and Basic Samples they couldnt read avisnet.dll file it didnt look like .Net or COM component. I simply deleted avisnet Reference and added Reference to AVLib.dll. File Interop.AVLib.dll was created in internal folders. Now all work. As I see avisnet.dll is the same as Interop.AVLib. Here what I tried: I renamed internal file Interop.AVLib.dll to avisnet.dll, deleted Reference to AVLib, added Reference to new avisnet.dll which I copied to AVBin. You couldnt believe, it doesnt work: file Interop.AVLib required but not found. Ha, rename avisnet.dll to Interop.AVLib.dll file and update Reference all work, of course.

So, I suggest dont use avisnet.dll at all. Just add Reference to native AVLib.dll. File Interop.AVLib will be created automatically. All will work. I think we shouldnt rename this file to avisnet.dll because program looks for exactly Interop.AVLib. And of course adding ActiveX files are also required as before.

If you want to have file avisnet.dll in AVin folder (for example, to show that .Net is supported :)) it must be named Interop.AVLib.dll but file will be unnecessary actually. You can research it.


5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

There was a build snafu with the 9.0 release that resulted in the Win64 version of theavisnet.dll file being put on the kit.

Anyway, as you noted it doesn't seem necessary to include avisnet.dll at all.As an experiment Itried creating a C# console program, added avlib.dll to the projectreferencesand was able to build and run the following sophisticated program:


Avis.Objmod.Group group = new Avis.Objmod.GroupClass();
group.Name = "foo";
Console.WriteLine("group name: " + group.Name);

I can see that the file Interop.AVLib.dll was created automatically in the project's obj directory.

So it seems we can dispense with avisnet.dll altogether. I guess I was under the impression that you had to use "tlbimp avlib.tlb" to get the type info imported, but that doesn't seem to be the case. For the next update I'll remove the avisnet.dll file and update the C#, VB.Net samples to use Interop.AVLib.

As a C#/VB.Net developer, how useful do you find AV? Do you have any suggestions for ways in which AV could be mode more suitable for .Net development?

Probably I didnt understand but I havent used "tlbimp avlib.tlb". I did the same ting as you and renamed Interop.AVLib.dll to avisnet.dll for my investigation. Anyway now it works and I think it isnt necessary to add any files to project explic-itly at all. Just ask user (for example, in Users Guide Language Considerations) add Reference to AVLib.dll. As you could see necessary Interop.AVLib.dll file will be created in internal folders and everybody will happy.

What about usability, AV is more easy to use in .Net languages, I say. I use C# in this case. I think Windows none console applications must be developed on .Net technology to get access to more ability. Another question: is it required for scientific-oriented applications? But anyway, interface doesnt require speed. Functions like Recalculate can use DLL Fortran unmanaged code. There are some approaches that could allow in future make more easy create .Net applications with important and significant fast unmanaged Fortran code. I always can say my suggestions. I dont know which way will choose Intel in this case but only not whole managed Fortran code (as some corps did). Im sure they understand it and without me.

I've deviated from question. While comparing Fortran and C# realization Im of opinion that its impossible to use Array Viewer in .Net. At least because subroutines like avNewViwer and avVisible are not able from .Net. But as I said its quite interesting and easy to use Object Model with ActiveX controls in .Net so adding this ability isnt really necessary, I think.

I noticed that Fortran subroutines looks the same as Fortran OM-subroutines they all have av prefix. Is it right? I do not know. Probably when Fortrans OOP ability will be realized avName (avBorder) functions (a la properties) will become exemplars fields. Actually Im interesting why OM objects are not realized like Fortrans Derived Types but C# has them (real access to AV-objects) while using the same DLL!?

According to properties, its not C#-properties, actually, just public fields. So I can Set Border for AVGraph3d object in spite of the documentation Get only. In C++ we couldnt do that there is no set_Border function there. So this not docu-mented ability can harm to robust program.

Sometimes I do not understand for what for type cast are made: Data = (Avis.Objmod.Dataset)Root.Datasets.CreateDataset("data") in C#.

Of course I do not know all aspects of AV realization but understand that if you would like to make work with AV easy and max useful in any language youll have to design AVLib.dll separately for each language.

Interesting how .Net could create namespaces from unmanaged AVLib.dll or its managed :)?

I hope I expounded my opinion and threw some ideas. I do not have much experience in using AV in C# but be sure I would certainly say you my other ideas and suggestions for improving usability of AV in .Net and not only.


Thank you for your comments!

The idea of IVF support for managed code comes up from time to time in the Visual Fortran forum, but the product team does not have any immediate plans in that direction. As you mentioned it is not very hard to call native Fortran dlls from a managed code, so that seems to be the way to go. Creating a UI with C# or VB.Net and calling into Fortran computational routineslets you use each language for the task it's best suited for.

It's not hard to use Array Viewer from.Net. Array Viewer support an Automation interface that can be driven from .Net. Just click on "Add Reference" in VS.Net and browse to ArrayView.exe. I've attached a C# sample that uses Array Viewer to display data rather than an AV control.

This sample also illustrates a new feature that allows you to read/write a subset of the dataset data using theReadData/WriteData methods of AvDataset.

The Fortran AvObjMod module is a Fortran wrapper for the Object Model interfaces. It provides some conveniences compared with calling COM directly from Fortran: No need for AddRef, Release, methods accept Fortran strings rather than BSTRs, etc. I guess once the Fortran team complete the OO features of the 2003 standard, we could have a more C#-like interface to the Object Model, but I think the AvObjMod interface is quite handy. I find it much easier to write programs in Fortran w/AvObjMod than C++ with the AV COM interfaces!

I'm not sure exactly what the conventions are for C# type cases.I just end up throrwing type cases in when I see compile errors. VB.Net seems much more less finicky about getting the types just right than C#.

AVLib.dll is unmanaged. But it i
s a COM library, so .Net can deduce methods and properties from the embedded type info. For a non-COM native dll, you'd need to explicitly define the method signatures.

Please keep us posted on any issues you run into with C# and AV!


Thanks for answers.
Ive looked an example. It was very helpful.
What about Fortran and .Net it may be useful to create corresponding topic in IVC Forum where in one place users could expound their suggestions and discuss them. Probably we should wait for Fortran 2003 realization but this is another story

Leave a Comment

Please sign in to add a comment. Not a member? Join today