Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28615 Discussions

Visual Studio Per-User Project Options Files

fj_60
Beginner
1,186 Views

It is fairly common practice to include a Visual Studio Solution when distributing software, not only to build binaries but also to include projects illustrating their use. Often, for the latter, a working directory and environment variables are required to be set in the Debugging Configuration Properties for the example projects to be run from within Visual Studio. This is true for both C++ and Intel Fortran projects. In the case of C++ projects the Debugging Configuration Properties are saved in a generic .vcxproj.user file that can be distributed with the project. In the case of Intel Fortran the properties are saved in a specific .vfproj.username.user file which, although can be distributed with the project, will have no effect unless the user happens to have the same username as the developer. There is a workaround that involves editing the .vfproj file which results in a specific user file being written when Visual Studio is closed though, as the documentation states "CAUTION Directly modifying these files with a text editor is not supported", it's probably not the preferred solution. I have tried other generic sounding .user files such as leaving out .username (as in C++ projects) or usernames such as default, public, or all, without success.
Does anyone have any suggestions? Have I missed something obvious? and for Intel: Is there a preferred way of distributing generic user options, eg a generic .user file name? If not, is the editing of .vfproj files unsupported in the sense that it is undocumented or that the format of the file can change from release to release and something that works now may not work in future releases?

(I have just found that, in essence, this topic was raised some time ago https://community.intel.com/t5/Intel-Fortran-Compiler/Project-settings-saved-per-user/m-p/1025408 which although recevied a reply it didn't resolve the question.)

0 Kudos
4 Replies
Steve_Lionel
Honored Contributor III
1,160 Views

There is no generic form of the .user files that I know of. I'm the one who put together the sample projects Intel distributes, and I never found the need to include a .user file. My experience is that the user file contains Debugger values, which do include environment variables, though how you would want those preset for a sample I don't understand - can you show what you'd want to do here? In cases where the user needed to do something, such as enter a file path, I provided a README file with instructions.

0 Kudos
fj_60
Beginner
1,147 Views

Thanks for the reply. Yes, I guess a readme file with some instructions could be a way to go. The use case that I'm having the issue with is as follows: the software is supplied with a root directory that has a readme and other info. Subdirectories contain different versions of binaries, in this case dlls, different versions of libs, C header files, documentation and examples. The examples directory contains subdirectories for different languages, C, C#, etc., etc. and Fortran. The Fortran subdirectory has subdirectories for different build environments, eg fpm and Visual Studio. The Visual Studio directory contains the .sln file and subdirectories containing individual Fortran projects that illustrate various aspects of the software. To be code-compatible with some other environments, and because the projects use and modify the same files, ideally the working directory of a project should be the project parent directory, ie Working Directory set to ..\ in the the project's Configuration Properties Debugging property sheet. When running a project the appropriate dll should be in the path which I'd like to set as a relative path in the Environment properties of the Debugging property sheet. I'm not sure how you get around the first problem. A kludge for the second is to copy the appropriate dll to the directory containg the project .exe in a Post-Build Event - but that feels as bad as, if not worse than, using 'unsupported' .vfproj files.

0 Kudos
Steve_Lionel
Honored Contributor III
1,132 Views

A copy of the DLL in a post-build step is a classic way of handling this. All the paths you need are available through VS predefined environment variables. Look at the various DLL projects in the samples bundle.

0 Kudos
MWind2
New Contributor III
1,131 Views

I never tried to directly modify vfproj files, but if one uses $(macros) in the solution to evaluate paths of items most things can be portable. I tend to use the non fortran objects to get the fortran since the $(macros) are provided and expanded, but have at times used the fortan project settings with $(macros). I've forgotten where or when, but at one time there was access to those for even fortran projects.

0 Kudos
Reply