Visual Studio 2008 Integration

[bitslayer]

So I am sorry if this is obvious to some, but I am not clear. Is the fortran compiler version 10.1.xxx supposed to work in Visual Studio 2008?

I installed studio 2008 and the fortran compiler and it seems 2008 is unaware of anything fortran.

Please help,

thanks.

[Les_Neilson]

Quoting - bitslayer

So I am sorry if this is obvious to some, but I am not clear. Is the fortran compiler version 10.1.xxx supposed to work in Visual Studio 2008?

I installed studio 2008 and the fortran compiler and it seems 2008 is unaware of anything fortran.

Please help,

thanks.

I have VS2008 and IVF 10.1.025 installed without a problem.

The order of installation is VS2008 (and Service Pack 1) followed by IVF

You could try running the IVF installation again.

Les

[bitslayer]

Quoting - les_neilson

I have VS2008 and IVF 10.1.025 installed without a problem.

The order of installation is VS2008 (and Service Pack 1) followed by IVF

You could try running the IVF installation again.

Les

Thanks for replying...how should it look in vs2008? Should there be a project type for fortran? I made sure to install SP1 and then reinstalled IVF...no obvious way to make/compile fortran projects...

[TimP]

The earliest 10.1 versions don't support VS2008 integration; they work with VS2008 only on command line.If you have the CD version, for example, you must register your license at https://registrationcenter.intel.com and download an update. VS2008 Express supports only command line, 32-bit only.

[bitslayer]

Quoting - tim18

The earliest 10.1 versions don't support VS2008 integration; they work with VS2008 only on command line.If you have the CD version, for example, you must register your license at https://registrationcenter.intel.com and download an update. VS2008 Express supports only command line, 32-bit only.

I am using downloaded "evaluation" version 10.1.025. Is this good enough? In VS2008 (regular edition) I do not see any project types or anything...

Any ideas?

[TimP]

Yes, the evaluation download is OK, if you have installed VS with C++ support, and, if installing 64-bit compiler, X64 development support.

[Les_Neilson]

Quoting - bitslayer

Thanks for replying...how should it look in vs2008? Should there be a project type for fortran? I made sure to install SP1 and then reinstalled IVF...no obvious way to make/compile fortran projects...

If you open up VS 2008 then under File->New-Project the dialog box should contain Project types one of which should be Intel Fortran with sub-types of Console Application, Library, QuickWin, Windowing App, and COM Server.

If you don't see that then something went wrong with your installation / integration.

The File->New->Project From Existing Code option only seems to know about C++, C# and Visual Basic

Under Tools->Options you should also see an "Intel Fortran" item. The "compilers" sub-item allows you to choose which compiler version to run - if you have more than one installed. Again if you don't see this then your installation and integration failed for some reason.

Les

[bitslayer]

Quoting - les_neilson

If you open up VS 2008 then under File->New-Project the dialog box should contain Project types one of which should be Intel Fortran with sub-types of Console Application, Library, QuickWin, Windowing App, and COM Server.

If you don't see that then something went wrong with your installation / integration.

The File->New->Project From Existing Code option only seems to know about C++, C# and Visual Basic

Under Tools->Options you should also see an "Intel Fortran" item. The "compilers" sub-item allows you to choose which compiler version to run - if you have more than one installed. Again if you don't see this then your installation and integration failed for some reason.

Les

Interestingly enough. When i first installed, i installed fortran then the visual 2008. I thought re-installing fortran would do the trick. It didn't. But uninstalling and then re-installing the fortran download...that did the trick!

Thanks.

[Groundsel]

Hello,

I have been beta testing IVF 11.0.039 with Visual Studio 2008. The Visual Studio 2008, however, is just a demo version with expiry date (in January I believe). I tried it out on one of our large solutions with 94 projects each of which generates a dll or an exe. In addition to the expected files, it also generates a number of other files with extension intermediate.manifest. So, for instance, a project which is expected to generate Y_ADJ.exe also generates Y_ADJ.exe.intermediate.manifest and similarly dll projects generate a .dll.intermediate.manifest

Prior to this beta test, I had worked with Visual Studio 2003 and was trying to kill two birds with one stone (anticipating the future of our software usage). Are these higher versions of Visual Studio than 2003 expected to produce these intermediate manifest files? Or does this indicate an unfortunate synergy between my demo VS2008 and the compiler?

I hope I am not going over well trodden ground.

Cheers!

Tom Stevens

[Steven_L_Intel1]

That's normal behavior for VS2005 and later. You can ignore the manifest files if you wish, or disable their creation in the Linker property pages. If you want to read about how they are used, some references are:

Manifest Files Reference (MSDN)

Shared Assembly Tutorial

[Groundsel]

Steve,

Is there any point to keeping these manifest files? Our "solution" consists of 94 projects which produce exe and dll files targeted to a single directory,the dll'saccessed by the exe's. Obviously, we have got on without manifest files before. Would their inclusion enhance efficiency in some way? Or become mandatory when a higher version of Visual Studio than 2003 is used?

Your previous answer suggests they are, at best, useful.

Tom

[Steven_L_Intel1]

I would say that "if you have to ask, you don't need them". You can ignore the manifest files and there's no need to keep them around if you aren't already using them. Manifest files can be useful if you are distributing your application to others using an installer, but many people don't use them and proper use requires additional steps.

I will comment, though, that it is not a good idea to have multiple projects sharing a common "output directory". If what you have done is change the linker output setting, that's ok. You may also want to turn off "generate manifests" if you find them "in the way".

[Steve_Nuchia]

Quoting - Steve Lionel (Intel)

I will comment, though, that it is not a good idea to have multiple projects sharing a common "output directory". If what you have done is change the linker output setting, that's ok. You may also want to turn off "generate manifests" if you find them "in the way".

In Visual C++ it is useful to use a common output directory but it does not work well at all with IVF through version 10. Of course you want to use separate intermediate folders in either language but in C++ you can put them wherever you want; in IVF you pretty much have to leave them where they are (in the source tree). In version 11 both of these issues have been addressed, though I can't say how well because we aren't going to get serious about adopting 11 until after our next release.

Configurarion management / release engineering / toolsmithing / whatever you want to call what I'm doing gets the short end of the design and testing stick with all the tools vendors, it seems. On the other hand the changes in 11 that address these issues appear to have been prompted by my trouble ticket on them; IVF has the best support ever.

[Groundsel]

Quoting - Steve Nuchia

In Visual C++ it is useful to use a common output directory but it does not work well at all with IVF through version 10. Of course you want to use separate intermediate folders in either language but in C++ you can put them wherever you want; in IVF you pretty much have to leave them where they are (in the source tree). In version 11 both of these issues have been addressed, though I can't say how well because we aren't going to get serious about adopting 11 until after our next release.

Configurarion management / release engineering / toolsmithing / whatever you want to call what I'm doing gets the short end of the design and testing stick with all the tools vendors, it seems. On the other hand the changes in 11 that address these issues appear to have been prompted by my trouble ticket on them; IVF has the best support ever.

Perhaps I used the wrong words in describing it as an "output directory". It was, in fact,the target into which all the executables and dll's were written. The application of the solution in question is a package of piping analysis software utilized in multi-step analyses. So it seemed sensible to direct the linker to place them together. That, in itself,has never been a problem.

What was more interesting -relative to what Steve said above - was that the manifest files do appear to be necessary. When I tried a rebuild (using the beta test compiler with Visual Studio 2008) and switching off the manifest files, it seemed to build OK - but on execution, I would get a failure message about the unavailability of MSVCR90.dll I don't know what it does. However, restoring the manifest files to the build delivered executables which seem to work.

[Steven_L_Intel1]

Ah, right. If you disable the manifests, then you have to make sure that all DLLs, including the MSVC DLLs, are in the "normal" places Windows expects to find them, such as the directory containing the EXE or PATH. Of course, this does not apply if you link to the static libraries.

When linking to DLLs, the MS DLLs all use shared assemblies and manifests are thus required if you don't make the DLLs visible elsewhere.

[Steve_Nuchia]

Quoting - groundsel

Perhaps I used the wrong words in describing it as an "output directory". It was, in fact,the target into which all the executables and dll's were written. The application of the solution in question is a package of piping analysis software utilized in multi-step analyses. So it seemed sensible to direct the linker to place them together. That, in itself,has never been a problem.

No, you're right on the money relative to Visual C++ vocabulary. The build system defines $(OutDir) and $(IntDir) and by default various outputs of the compiler, linker, and auxiliarary tools (MIDL, for instance) are directed into one or the other. In almost all cases you can override the entire pathname of any ouput, using either macro or any other string. This breaks down in a few places but not in any way that has burned me yet. C# is another story; I have almost no control over where it puts things without manually editing the project files and the defaults cause extensive grief when maintaining 32- and 64-bit builds from the same source tree.

IVF 10 fails to permit using the C++ model in a couple of ways. First, the build log uses a fixed name in the output folder so at best you get only the last one and in the case of parallel builds you get error messages due to the collision if you use a common output folder. And there are intemediate files that do not honor the setting of IntDir so if you move it the build just fails. The Beta for 11 addressed these issues but there were some glitches in the inheritance of other macros from the VS build engine (plus a new standards conformance error affecting legacy code) so I never got it completely the way I want it.

The manifest thing is a huge mess. It's probably justified but it's documented in the usual Microsoft way -- badly -- and it strikes us dinosaurs as a newfangled gimmick best ignored. That's why we're becoming extinct, probably.

[Groundsel]

Thank-you, chaps, for this useful information. I wonder if my redirection could have anything to do with an issue I raised with the beta test team. (Issue #517715) In it, the demo version of VS2008 interacting with the beta test compiler could not find the compiler executable at a critical point in the compilation. It was as if it forgot where it was. That issue has been closed since it was the demo VS2008 which I was using with no early prospect of being able to get the release VS2008. This happened on only 1 of 94 projects within a solution and one which compiles without incident when the same beta test compiler is coupled with VS 2003.

Any thoughts?

[Groundsel]

Belie that! I now know what the causative factor was in issue #517715 and it has nothing to do with VS 2008 integration or my use of a single target directory for the build. I have reported it to the beta test team but believe it predates that compiler. One gets the message about the absence of fortcom whenever he disappears an underlying source file but leaves it in the solution explorer. (Don't ask me how I managed that!)

Cheers!

Tom