Distributing apps

Distributing apps

Earl Geddes's picture

I build application in VS using VB.net and FORTRAN.  I can always run my code on my own machine or any machine with the Intel FORTRAN compile installed, but I have not had any success in creating a deployment package that will run on a machine without the compiler.

Could someone who has done this run down what is required?

What DLL's must be distributed with my application to use my FORTRAN DLL in the VB.net program?

Obviously the VS deployment Wizard does not work for this example because it knows nothing about the FORTRAN DLL.

Any advice or articles would be greatly appreciated.

Earl Geddes PhD.

President
GedLee LLC

23 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Tim Prince's picture

If you don't want to include the entire redistributable library package for the compiler, wouldn't running something like dumpbin /dependents yourfortran.dll (or dependency walker) tell you which ones to include?  Couldn't you verify in an environment where you didn't set up visual studio or ifort paths?

The libraries you will need to include evidently depend greatly on your built settings.

Which questions do you have which weren't dealt with in posts such as http://software.intel.com/en-us/forums/topic/289496

(if I am not spam blocked for referring to another forum post)

mecej4's picture

There is a downloadable redistributables package for exactly this purpose:

     http://software.intel.com/en-us/articles/redistributable-libraries-for-i...

 

 

IanH's picture

If you are building an msi (is that what the deployment wizard ends up building?), there are also merge modules that achieve the same outcome as the downloadable re-distributables that mecej4 mentions.  These merge modules (.msm) are provided in the redist subdirectory of the compiler install.

They are pretty easy to add to VS2005 through VS2010 Visual Studio deployment projects.  The resulting msi will require elevation (administrator access) in order to be installed.

Earl Geddes's picture

Thanks - that's helpful

I am guessing that one must create an new "project" in VS that uses the redistributable run-time libraries.  The "one-click" method won't work as it does for a VB.net project.

Can the linked zip file just be sent to the final user and loaded on their system or does it have to be installed via an MSI project?  This part is not clear now that it is clear that I must distribute run-time libraries.

None of this was explained in the link that was provided.  And of course Microsoft does not explain it in the Visual Studio documentation for Intel FORTRAN.

 

 

Earl Geddes's picture

I did not find any .MSM modules anywhere.  Could you be more specific about where they are and how they are used.

One-click does not build an MSI project, just a setup.exe.

I have never had to distribute a FORTAN DLL in any of my projects before so I just used On-Click.  But what it creates errors inside the FORTRAN DLL with an unresolved dll reference.  I am sure that this is a run-time library, but I am not sure how to get it on to the remote machine.

Earl Geddes's picture

PS.  I gave up on Microsoft when they admitted that One-Click does not correctly distribute all the required DLLs for any of their products.  They washed their hands of it when they learned that it was a FORTRAN DLL, which is why I came here.  Seems like they don't support VS very well for FORTRAN users (even though the main program is VB.net.)

IanH's picture

If the zip you are referring to is the one that mecej4 referred to, then my recollection is that you will find msi files inside, one for each platform type.  On the client machine you would install the msi that corresponds to the DLL's platform (32 bit or 64 bit).  The 64 bit installation is not relevant to a 32 bit machine, but there's no problem installing both 64 and 32 bit runtimes on a 64 bit machine. 

Going via this method it typically be done as a separate installation step from the install of your actual application (though you could probably chain the install from your applications install).  In the short term this might be the easiest approach.

I'm not familiar with the one click stuff.  I'm equally unfamiliar distributing vb.net stuff.  But what I used to do within VS (up until 2010 - what version are you using?) was to have a "Setup project" that built a msi that installed my executables, my DLL's and the Fortran and C++ runtime dll's.  I understand that this sort of project is no longer available in current Visual Studio (I still use 2010) but I presume there's some sort of equivalent capability. 

(In the meantime, because I wanted more control over the installation process I've migrated to wix based installs, so hence my recollection and advice is a bit hazy.  That additional control comes with increased complexity.)

[C:Program FilesIntelComposer XE]

	>dir *.msm /s

	 Volume in drive C is OS

	 Volume Serial Number is 5E42-58E5
 Directory of C:Program FilesIntelComposer XEredistia32compiler
2013-10-18  12:33 PM        17,891,328 w_fcompxe_redist_ia32_2013_sp1.1.139.msm

	               1 File(s)     17,891,328 bytes
 Directory of C:Program FilesIntelComposer XEredistintel64compiler
2013-10-18  12:33 PM        24,121,344 w_fcompxe_redist_intel64_2013_sp1.1.139.msm

	               1 File(s)     24,121,344 bytes

Earl Geddes's picture

IanH

I have VS2008, VS2010 and VS2013.  I have seen the setup project option and loaded it once and even generated a MSI file.  But it still didn't work because I didn't include the FORTRAN Run-Time libraries. (It is apparently NOT automatic.)  I am not sure how to include them.  The *.msi generation was a new road for me as none of it was familiar.  Going the route that you have gone may be more flexible, but what I need is simpler not more complicated.  This is not a commercial application, I only want to send it to a few colleagues.  It's not worth a huge investment to learn an all new language for setting up a distribution file.  Under VB6 it was so simple, even with a FORTRAN DLL.  Now it seems like it takes an expert just to distribute an app. 

The zip file only had a bunch of DLLs and no instructions that I could find.  kind of disappointing.

David White's picture

When you build your app, you may want to use the Multithreaded option for the Run-time library.  In this way, the required DLL's are incorporated into your app, and you do not need to distribute additional files.

For creating setup files to send to other users, I use HM NIS Edit, which is available from sourceforge.net.

Regards.

David

Earl Geddes's picture

Hi David

Yes, I read that you could do this somewhere, but as with everything that I am finding out about distributing a program it is not well documented how this is done.  The "Multithreaded option" is a switch in the Linker under the FORTRAN project properties?  Is this not the default?  I looked at this switch and it appeared that "multithreaded" was the default.

Building a means of distribution for a multi-language application in FORTRAN is a sadly lacking aspect of this package both from the Visual Studio side as well as the Intel FORTRAN side.  I have a lot of experience on both ends, but putting them together is not so easy and neither end seems to take ownership of this task.

Earl Geddes's picture

I tried HM NIS Edit but it would not run on my Win 8.1 computer.  I had no idea how to even start.  I tried the Wizard, but it locked up.

Oh well!  Worked out just about like everything else that I have tried. Thanks anyway.

IanH's picture

Quote:

Earl Geddes wrote:

I have VS2008, VS2010 and VS2013.  I have seen the setup project option and loaded it once and even generated a MSI file.  But it still didn't work because I didn't include the FORTRAN Run-Time libraries. (It is apparently NOT automatic.)  I am not sure how to include them.  The *.msi generation was a new road for me as none of it was familiar. 

If you have the sort of setup project that I think you have (and are using a full edition of VS <= 2010), you right click on the project name in the solution explorer, then select Add > Merge module.  You will then get a file selection dialog, that has probably opened in the directory where Microsoft stashes all its merge modules (some of which may have already been added to your setup project by dependency detection).  Navigate your way to the relevant merge module under the intel hierarchy and select that.

In addition to the Fortran runtime you also need to distribute the VS C runtime that the Fortran runtime uses (because of the prevalence of VS built Cpp applications, that is very often already installed on a machine as part of some other application, but you should not count on that).  You can find the relevant merge modules for that in the initial directory that the add > merge module thing opens in.

Attached a screen shot of the VS2010 deployment project for something I'm working ... on on the side ... for a 32 bit program built using ifort 14.0.1 under VS2010.

Quote:

The zip file only had a bunch of DLLs and no instructions that I could find.  kind of disappointing.

I don't think you picked the right zip file then.  I just followed mecej4's link and downloaded w_fcompxe_redist_msi_2013_sp1.1.139.zip from the links in the small table towards the bottom of the page (fortran column, update 1 row) and it contains the two platform installation msi's. 

(There's a similar vcredist.exe file for the C++ runtime that you can download from microsoft, VS2010 SP1 here for example.)

David's suggestion for static linking might also suit.  I'm not sure how that interacts with the the .net main program though.

Attachments: 

AttachmentSize
Download setup_1.png58.83 KB
David White's picture

Re: Library Options - it is under Fortran / Libraries.

Make sure you do not confuse Multithreaded (= static) with Multithreaded DLL (=dynamic); the latter needs the redistributed files.

Also, remember if you are redistributing files, that the license conditions only permit redistributing the Release version of the libraries, not the Debug versions.

Regards,

David

Earl Geddes's picture

Ian

There is no "Add > Merge module" in my VS2010.  I have the academic version since I am a Prof.  Does this mater?

Earl Geddes's picture

Ian

There is no "Add > Merge module" in my VS2010.  I am using the Academic version since I am a Prof.  Does that matter?  Seems like Profs might want to distribute some app to their students.

I did pick the correct file, but did not find any "merge" modules as described.  I tried searching for them in Windows but it did not show up anything.

IanH's picture

To be clear - at the link mecej4 posted (http://software.intel.com/en-us/articles/redistributable-libraries-for-intel-c-and-visual-fortran-composer-xe-2013-sp1-for-windows) you will find links to zip files (the zip files are compiler version specific, but there is usually no reason that you cannot just use the one for the latest version - which you will get here) that have inside it two installations (msi files) - one for 32 bit, one for 64 bit, of the ifort runtime.  You unzip the zip, pick the msi file that is relevant to your program, copy it to the client machine, double click on it, follow the prompts and you are done from the point of view of installing the ifort runtime.  You don't need to interact with any merge modules as part of this process.  You only need to install the runtimes once per machine per compiler version, regardless of how many times you then install your specific application to the machine.

You also may need to (perhaps "should") install the Visual Studio C++ runtime libraries.  They are platform (32 bit/64 bit) and Visual Studio version (and service pack) specific.  Microsoft provides these as a download called vcredist_xxx.exe or similar.  Your favourite search engine can help - see this for an example.  Again, no merge modules involved if you go this way and again, you only do this once per machine per Visual Studio version.

If you don't go down the static linking path, then sending out the relevant ifort runtime msi and vcredist thing along with your clickonce thing would seem to be the simplest approach.

In terms of the Setup project approach, I can't really (well... perhaps shouldn't) comment on editions of VS other than the professional one, but I am a little surprised that if you can create deployment projects that you cannot add merge modules.

(Edit to add screenshot showing the deployment project selected in the solution explorer and the relevant menu item - this is for the VS 2010 professional version.  If the forum gods are listening - the attachment thing is playing up - files get uploaded (I can see them via my files) but they don't necessarily appear in the post.)

Attachments: 

AttachmentSize
Download menu_0.png64.62 KB
Earl Geddes's picture

Hi Ian

I get the picture now.  I clicked on the *.msi and it did install all the DLLs, but I was thinking that what was meant was that an MSI or merge module would be installed, but that is not what happens.  I get it now, I distribute the zip (or *.msi) directly to the client and they run it.

I also see that you are talking about an "install" project - I don't have one of those, I have been using one-click, which, as I said, does not work if there is a FORRAN project.  What you suggest might work, makes sense now that I see the bigger picture.  I'll try that and get back.

Earl Geddes's picture

OK, I tried setting the FORTRAN options to "Multithreaded" (it does not say static)  but the DLL is the same size as before and dependency walker shows that the DLLs are not embedded.  Am I doing something wrong here.  I am following all the advise as close as I can but it is not working as claimed.

Any suggestions.

IanH's picture

Copy the contents of the command line page in the properties of the Fortran DLL project and paste here.

Earl Geddes's picture

/OUT:"Release\ModesCalc.dll" /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Users\Earl\SkyDrive Pro\Projects\Modes\ModesCalc\Release\ModesCalc.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:WINDOWS /IMPLIB:"C:\Users\Earl\SkyDrive Pro\Projects\Modes\ModesCalc\Release\ModesCalc.lib" /DLL

Maybe the error is that I set this in the "Release" but I think that VS set it back to "debug", because I had the "debug" setting for the VB code.  When I went back in it was reset to "Multithreaded DLL".  I don't know when that happened.

I know find a much larger DLL and I guess that it is working.  VS studio does some things with a FORTRAN project in the same solution as  VB project that I don't expect.  You have to set BOTH the VB project and the FORTRAN project to "Release" or it will set the FORTRAN project to "Debug" and reset the "Library" settings.

IanH's picture

That's the linker command line, not the Fortran compiler command line.  In the properties dialog have a look under Configuration Properties > Fortran > Command line.

(Perhaps you already know this, but...) Visual Studio maintains a solution configuration that is typically Release or Debug (but you can define your own).  It maps that solution configuration through to project specific configurations, that usually have the same name.  You can see that mapping using Build > Configuration Manager.  Similarly there is a solution platform, mapped through to individual project platforms.

Each project has a relatively independent set of properties for each combination of project configuration solution and platform.  Once the properties for a particular combination have been created, if you decide to make a change such as going from dynamic to static runtime libraries, then you need to make that change in each configuration+platform combination.  It is easy enough to forget to do this for a particular combination.

The properties show by default when you first open up the project properties dialog is that which the current solution configuration and platform map to.  Within the dialog you can then edit the properties for different project configuration+platform combinations.  Once you start doing this it is easy enough to get confused between the current combination and your specific selection.

Earl Geddes's picture

Thanks Ian

I did solve the problem.  I am not sure what happened, but given how confusing your description of the configuration was (and yes I knew about that, but didn't realize that it had to be changed everywhere) I am sure that I got it wrong.  I set the project to "Release" for both projects and then the "static" linking for the FORTRAN and it compiled a DLL that runs fine at the clients site.

Thanks again for all your help.

Login to leave a comment.