Integration of psxe 2016 in VS2010

[John_Ludwig]

I am trying to use the 2016 compiler in VS 2010. Everything looks fine, it knows about the Fortran, and I can open the sample 'Hello world' project. However, when I try to compile the source file with right-click/compile I get a 'The operation could not be completed' error message. Further, if I right-click on any item e.g. the source file in the Solution Explorer tree end select 'Properties',  I get 'Class not registered. Looking for object with CLSID: {F0F74B93-6F3C-4212-897A-DF6A62B91A8AJ}.

I have repaired and modified the compiler installation several times, with no effect. I have tried to unregister and register the dlls following 'https://software.intel.com/en-us/articles/troubleshooting-fortran-integration-issues-with-visual-studio'. All four unregister, but VFProj.dll always fails to register again, with, I believe, an 'access denied' error. In regedit the permissions for HKEY_CLASSES_ROOT are 'full' for system and administrators, as also for CLSID.

In a command prompt I can compile, link and execute the 'Hello world' example, so it must be linked to the VS 2010 integration somehow..

The machine is running Windows 7, and I have a successful integration of ComposerXE-2011 in VS2008.

Does anyone have any ideas on how to solve this problem?

Thanks,

John

[Steven_L_Intel1]

This thread discusses a similar problem a customer had years ago - it may provide some clues. You may be running some security software that prevents registry changes, or has modified the registry to block changes. Let me know if this helps.

[John_Ludwig]

Hi Steve,

Following the hints in your post I eventually tracked the problem down to the registry key VisualStudio-idl.10.0. Regedit would not let me change permissions (or anything else!) even as Administrator. Further research led to changing ownership of this key, which I could only do in Safe Mode. Somehow the ownership of this key was different from, say, VisualStudio-idl.9.0, so I reset the ownership and permissions to be the same. After a reboot the integration repair for VS2010 worked and all four dlls were registered, and I can open, compile and build the 'Hello world' example.

It took three days, and at one point I was within 5 minutes of re-installing Windows as my registry was so messed up, but in the end I got there!

Thanks for the suggestions,

John

[Steven_L_Intel1]

Glad to hear it - this sort of problem can be very difficult to resolve and even more difficult to identify the cause. What had the owner been set to?

[John_Ludwig]

Hi Steve,

As I recall the owner was set to my own login id. How that happened is beyond me! The keys above and below in the list were all owned by SYSTEM.

I have a follow-on question, which there may be an existing answer to. In my 'real' VS2010 project, I have a solution, say total.sln, which contains a C project, c-proj.vcxproj and a Fortran project, f-proj.vfproj. c-proj creates c-lib.lib, which contains the main program. f-proj creates f-lib.lib. The project dependencies and build orders are set to that c-proj depends on f-proj, and f-lib is built before c-lib. So far so good, and both libs are built. When I link, all the subroutines in f-lib referenced by c-lib are unresolved. In my equivalent VS2008 project, the Linker Command Line (for c-proj) shows that f-lib.lib is included in the list of libraries. In the VS2010 Linker Command Line f-lib.lib is absent. If I add f-lib.lib as an 'Additional option' then the link works. Is there some setting I am missing, as I would have thought including the lib created by another member of the solution should happen automatically?

If this should be a separate question, then I can re-post.

Thanks,

John

[mecej4]

There are two sets of dependencies, and mixing them up can lead to confusion. The first group is run-time dependencies, such as calls to library routines in static or dynamic libraries, and the Fortran runtime. The second group consists of compile-time dependencies. If your source code is all old-style Fortran (and C, possibly), with no Fortran modules in play, and you do not use include files that have been changed, the sources can be compled to OBJ files in any order since there are no compile-time dependencies. Once all the OBJs, libraries and DLLs have been built, in any order, you can link your application; only the link step has dependencies.

When you specify to Visual Studio that one project depends on another, you are telling it that the projects are to be built in a specific order. In some versions of VS, when you specify that your EXE depends on a LIB that is part of the same "solution", the LIB may be added to the linker command line for the EXE; if not, you have to specify the library on the linker properties of the EXE project. I have not bothered to keep track of which versions of Visual Studio add dependency libraries to the link command of a dependent EXE, because the fix is so simple.

[Steven_L_Intel1]

mecej4 has most of it, but the answer gets more complicated with newer VS versions. 

Fortran projects use "Project dependencies". As mecej4 says, this determines build order but also causes the output directory of dependent projects to be added to the INCLUDE/USE path and causes libraries from dependent projects to be included in the link.

If your Fortran project is a static library that depends on other static library projects, you need to set the property Librarian > General > Link library dependencies to Yes.

Now comes the complications. As of VS2012, C++ projects no longer link in dependent non-C++ projects, so you have to explicitly add any Fortran libraries to the list of "Additional Dependencies" and also add the path to the libraries. Also, in VS2010 C++ changed to using MSBUILD, which doesn't recognize Fortran, so if you convert an older mixed-language solution you have to redo the dependencies and this is probably what you ran into. Here's the instructions from one of our mixed-language samples so you get the idea:

Visual Studio 2010 Project Preparation
======================================

Microsoft Visual Studio 2010 has made significant changes in the way dependent projects work.  If you
opened this sample solution in Visual Studio 2010, the conversion left some settings which need to be
changed before you can build.

- Open the solution
- Right click on the C_USEDLL project and select References
- FDLL.vfproj should be highlighted.  Click Remove Reference.  Click OK.
- Right click on the C_USELIB project and select References
- FLIB.vfproj should be highlighted.  Click Remove Reference.  Click OK.
- Right click on the C_USEDLL project and select Project Dependences
- Check the box Depends on > FDLL.  Click OK.
- Right click on the C_USELIB project and select Project Dependences
- Check the box Depends on > FLIB.  Click OK.

You can now build.

In addition to this you'll probably have to add the Fortran libraries to a C project.

Yet another complication is if you have a Fortran project dependent on a C++ DLL project. For some reason, C++ doesn't export the properties right so the .lib doesn't get linked in automatically - again, you'll have to manually configure this.

Hope this helps.

[John_Ludwig]

Thanks Steve, mecej4,

I had worked out the hard way that I needed to add the fortran LIB explicitly to the linker, I was just wondering if that was a benefit of using VS2010, as in VS2008 it did it for you which seems much kinder. From your comments it's plain that MS changed the rules (again!) and we just have to remember where the LIB for each configuration is so that we can add the right ones. As mecej4 says it's simple, but a pain none-the-less.

Thanks for the help,

John