Convert exe project to dll?

[MZ2]

I have a Windows fortran project in parallel studio that is set up so that it builds an executable. The Configuration Properties -> General -> Configuration Type is set to "Application." What I would like to do is add another configuration that builds a DLL since I am going to convert this project to a dll and that, from my standpoint anyway, would be the easiest path forward for me as it is a large project that contains many 10s of fortran source files.

However, if I add a configuration using the Configuration Manager, I am unable to edit the "Configuration Type" property. For that matter, it seems that the "Configuration Type" property is not editable in any of the original configuration created for the project, i.e., either release or debug.

Is it possible to change the configuration type of an existing fortran project, or must I recreate the project from scratch as a dll?

Thanks.

[DavidWhite]

I expect that there are too many settings for a DLL project that differ from the exe project to make a simple change. 

Starting a new project would be safer.  It can still reside in the same MSVS solution, so that until you switch totally, you can build both the DLL and the EXE at the same time.

Having them in the same solution, means that as you work through adding the source files to the new project, you can have both files lists open, to make sure they are the same.

David

[IanH]

Another option is to have three projects:

- A static library project, that perhaps has the majority of source files and contains the "core" code of the thing you are writing in Fortran.

- An executable project, that links against the static library and contains source files specific to the executable (perhaps just the source of a Fortran main program).

- A DLL project, that links against the static library and contains source files specific to the DLL (perhaps the actual exports from the DLL are thin wrapper procedures).

When built together as part of the same solution configuration, the three projects need to have consistent runtime library settings.  Some additional specifications/settings may be required to export procedures in the DLL directly from code that is first compiled into the static library, depending on how you nominate the exported procedures.

This, typically, is my preferred approach.  Often I will have further projects that depend on the static library - test driver executables, alternative interfaces (C/matlab/excel/...), other things that seemed like good ideas at the time...

Unlike Microsoft VS C++ projects, the type of thing (lib/dll/exe) that a Fortran project builds is fixed when you initially create the Fortran project, if you want to create something different, you need to recreate the project.  That I might always change my mind later is then of the reasons that I pretty much always start by putting code, other than the main program, in a static library.

[MZ2]

Thanks for the replies.

For my particular case, I am moving away from the exe to the dll code.

It appears that once the configuration type is set, it is not changeable, as I noted, in the project properties. So, what I did was to create a separate project file for the DLL project, and leave the EXE project file as it was - which is what Ian suggests.

How I did this was to create an empty project as a dll. I then used a file comparison tool to compare the vfproj files from both. There is little difference except for at the root level of the xml in the file for the dll project, there is a ProjectType attribute that is set equal to "typeDynamicLibrary". In the exe project file, this attribute does not exist. Also, in the dll proj file there is a Keyword attribute that is set equal to DLL and in the exe, it is set to "Console Application"

DLL:

<VisualStudioProject ProjectType="typeDynamicLibrary" ProjectCreator="Intel Fortran" Keyword="Dll" Version="11.0" ProjectIdGuid="{2EDD18DA-2504-405E-953E-A0C437E3BBD9}">

EXE:

<VisualStudioProject ProjectCreator="Intel Fortran" Keyword="Console Application" Version="11.0" ProjectIdGuid="{16893328-7D81-4E46-86B2-B259A1D0106A}">

There areother notable differences:

These are in the configuration, compiler and linker Tool elements in the project files:

DLL:

	<Configurations>
		<Configuration Name="Debug|Win32" ConfigurationType="typeDynamicLibrary">
				<Tool Name="VFFortranCompilerTool" SuppressStartupBanner="true" DebugInformationFormat="debugEnabled" Optimization="optimizeDisabled" FixedFormLineLength="fixedLength132" WarnInterfaces="true" RealKIND="realKIND8" ByteRECL="true" FloatingPointExceptionHandling="fpe0" FloatingPointModel="source" Traceback="true" BoundsCheck="true" UninitializedVariablesCheck="true" StackFrameCheck="true" RuntimeLibrary="rtMultiThreadedDebugDLL"/>
				<Tool Name="VFLinkerTool" LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true" GenerateDebugInformation="true" SubSystem="subSystemWindows" LinkDLL="true"/>

EXE:

	<Configurations>
		<Configuration Name="Debug|Win32">
				<Tool Name="VFFortranCompilerTool" SuppressStartupBanner="true" DebugInformationFormat="debugEnabled" Optimization="optimizeDisabled" FixedFormLineLength="fixedLength132" WarnInterfaces="true" RealKIND="realKIND8" ByteRECL="true" FloatingPointExceptionHandling="fpe0" FloatingPointModel="source" Traceback="true" BoundsCheck="true" UninitializedVariablesCheck="true" RuntimeLibrary="rtMultiThreadedDebug"/>
				<Tool Name="VFLinkerTool" LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true" GenerateDebugInformation="true" SubSystem="subSystemConsole"/>

The specific differences are

1. The ConfigurationType attribute appears in the Configuration element for the DLL, but not for the exe
2. The RuntimeLibrary attribute for the EXE is different than it is for the DLL
3. There is an additional attribute in the DLL Tool element for the linker that is "LinkDLL" which is set to true. For the exe, this does not exist.
4. And also in the linker Tool elements there is a SubSystem attribute which is subSystemWindows for the dll and subSystemConsole for the exe

The exe was a windows console application as opposed to the other possible exe types.

I also added a source file to the dll project and looked for differences in the xml for the source files and found none. I then used the file comparison tool to copy the source file sections from the exe file to the dll file. This could have more easily been done using drag and drop had I created the project in the solution for the exe file to begin with.

I also visually compared the available settings between the exe and the empty dll project, and I notice no differences.

Anyway, this is probably way more information than necessary, but sometimes, it helps to have some in-depth info available.

The DLL builds. Now on to the task of using it. :)

Thanks again.

[MZ2]

Note that if the two projects are in the same solution, VS appears to become confused when selecting source files from the project that is lower in sort order. If you select a source file in the lower sort order project, the source file in the higher sort order project is selected.

Yes, I know. It is the fact that I copied the source file entries from the one project to the other; however, since my project is diverging away from being an exe, I consider that acceptable.