Visual Studio Per-User Project Options Files

[fj_60]

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.)

[Steve_Lionel]

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.

[fj_60]

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.

[Steve_Lionel]

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.

[MWind2]

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.