I am attempting to recreate a set of Fortran projects using Intel Visual Fortran (Parallel Studio XE 2013) with MS Visual Studio 2010. The projects had formerly been built using Compaq Visual Fortran 6.6, where they were all part of a single workspace. There are seven projects in the VS solution (what had been the workspace in CVF), of which three are static libraries and the other four are console applications that depend on the static libraries.
In addition, I have one Fortran module in a single file, in which all the type definitions reside, and which is included by means of the USE statement in each of the source files. In CVF this was included in the workspace as an "External Dependency", but MS VS 2010 does not seem to have the same property for its "solution". (?)
So here's my question: How do I add to the VS solution a .F90 source file that defines a module MODULENAME in such a way that when other source files call USE MODULENAME, the compiler will pull in the module MODULENAME defined in that file. I'll put it wherever MS VS wants me to put it, but I haven't figured out how to tell it where to look.
ANSWER: Thanks to everyone who answered down below. Based on those responses, I created a new static library project that contained the single source file that defines the module in question. I then set dependencies on this project for every other project that had any source files with the USE MYMODULENAME statement in them. Some of them might not have needed this dependency, if they already depended on other projects that depend on this module; I'm not sure about that. It doesn't seem to hurt to have the redundant dependencies; I assume that the IDE resolves this correctly and doesn't compile the module more than once.
For anyone who is as new to this as I am:
To add the module as a project, I right-clicked the solution and selected "Add New Project". In the dialog that popped up, I selected "Static Library" as the type.
To set the dependencies, I right-clicked the solution, selected "Properties" (there's also a button on the Solution Explorer toolbar) and went to the Dependencies panel.
You either:
Create a separate static library project for the single module that has just the single file, and then make projects that require that module/file depend on that static library project (one of the existing static library projects may already be a suitable container for this).
OR
Simply add the single file to each project that uses the module defined by the file.
Which is best mostly depends on what you think is best.
You can find this in Intel Fortran documentation:
use the -I (Linux OS) or /I (Windows OS) option to specify the path to search and locate the definedmod.mod file
So you need to compile your MODULE and accordingly set include directories in other projects Configuration Properties->Fortran->General->Additional Include Directories
Related
How do I add a Static Library to a VS 2015 Fortran Project?
I've searched for the answer to this question online, but the solutions I've found (linked below) don't seem to work for me.
How to link a .LIB in a MS Visual Studio / Intel Fortran project?
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/393843
I'm using VS 2015 and Intel Fortran 2017.
I have created a static library from my Utilities project and I would like to be able to use the 'Utilities.lib' file in a different project (PhysicsCore) without having all of the source included.
I've tried dragging and dropping the 'Utilities.lib' file into the PhysicsCore Project. I've tried adding existing file and adding 'Utilities.lib'. I've tried adding the lib file and all of the '.mod' and '.obj' files. I've tried going under properties -> librarian -> additional dependencies. All of these end with the PhysicsCore project failing to compile due to missing procedures and modules.
I have gotten it to work one way that isn't very helpful. I have added a new project to the solution and then added in all of the '.obj' and '.mod' files and the '.lib' file. Changed the solution settings to not rebuild that project. And then finally added that non-building project as a dependency of the PhysicsCore project.
I feel like I must just be missing something small.
EDIT: years later. I finally came across the issue. If the library were all in .f90 files everything would work fine, but I'm using modules which require the .mod files. Everything was doing what it was supposed to as far as I can tell; however, it didn't behave the way I expected it to.
There are several ways:
Drag the .lib into the project as a source file. You say this didn't work, but it always has when I have done it.
In the Linker project properties, add the full path to the .lib to Linker > Input > Additional Dependencies, or just add the .lib name there and add the directory path to Linker > General > Additional Library Directories.
If the parent project is also Fortran, right click on the parent project, select Build Dependencies > Project Dependencies. Check the box for the library project. (This does not work if the parent project is not Fortran.)
I would generally recommend #3, as this will also make the .mod files from the library project visible to the parent project. If you choose one of the other methods, you then also have to make any include or .mod files visible by adding the directory path to the project property Fortran > General > Additional Include Directories.
If you need more help with this, I suggest asking in https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows
I have this old VB6 project that is composed of a few DLLs, OCXs, and GUIs.
There is a GUI component that includes this in it's VBP file:
Type=Exe
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#C:\Windows\SysWOW64\stdole2.tlb#OLE Automation
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
Object={3050F1C5-98B5-11CF-BB82-00AA00BDCE0B}#4.0#0; mshtml.tlb
Reference=*\G{64E54C86-D847-48F7-9AE5-D6C9B8E6A3A2}#3.0#0#..\..\bin\Crypt.dll#Crypt
Reference=*\G{B3E7F95C-B6D9-458E-B4D4-5272759B139A}#4.0#0#..\..\bin\SpeechMike.dll#SpeechMike_DLL
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
Object={AB4F6C60-4898-11D2-9692-204C4F4F5020}#29.0#0; Ccrpsld.ocx
Object={48E59290-9880-11CF-9754-00AA00C00908}#1.0#0; msinet.ocx
Object={9C526969-AA6E-4D61-BAFA-117FD20C2B38}#3.0#0; SpeechMike.ocx
The Reference settings are a pain since they always change from one machine to the other. I mean, the GUID '9C526969-AA6E-4D61-BAFA-117FD20C2B38', for the last one as an example, will be something on my system, but something else on somebody else's machine.
For now, to make it work, I erase References to Crypt.dll and SpeechMike.dll. Also Object SpeechMike.ocx. Otherwise, Visual studio looks for something that does not exists. Then in "project > references" I check both Crypt and SpeechMike and the Reference goes back to the VBP with the proper GUID and version. Finally, in 'project > components' I add the OCX and I'm good to go.
Am I wrong about that? How can I share the project with some else without going through hoops and loops to start the project?
I'm using MS Visual Basic 6 (part of VS 6 enterprise).
This sounds like "failure to maintain binary compatibility." Normally you only do this to yourself, but of course it can be a bigger headache if multiple people are compiling your libraries from the source Project files.
When you create ActiveX EXEs, DLLs and OCXs you need to create a "base" version where type and class ID values (GUIDs) get assigned. The documentation even suggests that you do this leaving the procedures empty: just a comment line or something so the IDE does not remove the empty declarations.
You don't have to use an "empty" base reference library, it can be one with full code in it.
Once you have compiled this baseline library, you'd exit and save your Project. Then rename this "empty" library as something else and from there keep it along with your Project source files.
After this you re-open the Project and go into Project Properties and on the Component tab change the Compatibility setting to Binary Compatibility and in the box there enter the full path and name of your compiled baseline library. Save the Project. Now you can add code and compile the "real" library to be used by other programs.
When you distribute these libraries (DLLs, OCXs) to somebody else in source code form so that they can compile them you must provide this renamed compiled baseline library along with the source code files, VBP file, resource files, etc.
From there your GUIDs will be stable until you make a change to something that breaks binary compatibility (changing a method's argument list, etc.).
There is more detail on this in the online Help (MSDN Library). See:
Using Visual Basic|Component Tools Guide|Creating ActiveX Components|Debugging, Testing, and Deploying Components|Version Compatibility in ActiveX Components
I have several Visual Studio solutions/projects (some VB, some C#) that all reference a common DLL at design time. This DLL does not have to be copied to the output folder as it is only needed while writing code. Every few months this DLL will be updated to a newer version and all of my projects need to reference the updated version.
What is the best way to handle this?
You have to use a Shared Assembly, shared in GAC (Global Assembly Cache).
Say, you have programmed a class, a piece of software, whatever you have, and you want to make it a shared assembly.
First you make it an assembly by creating a new Class Library Project in VS and transporting all of the code to that project. Don’t build/run it yet! Note that we just transport the code but the assembly (the .DLL file) is not actually made yet, because we have not built the project yet.
Before building the assembly, we have to create/share a key by which the assembly is known, in 2 steps:
a) create the key by executing the cmd below in VS cmd:
sn -k "C:[DirectoryToPlaceKey][KeyName].key" b) share it by adding the attribute below to the AsseblyInfo.vb/cs file in the properties folder of your Class Library project:
In VB.Net:
In C#:
[Assembly: AssemblyKeyFile("C:[directory containing the key file][KeyName].key")] (just copy and paste this into the AssemblyInfo.vb/cs file, but write your directory and file name instead).
Now, you MAKE the assembly by building the project. Just build the project (just press F5 once, at least!). By doing so, the .dll file we need (the assembly) is created in the “bin” folder in the same folder of the project.
Now we share it by Copying the .dll file into the GAC (Global Assembly Cache: it’s where all the assemblies are gathered together. The directory is: “C:\windows\Microsoft.Net\assembly\GAC_MSIL” but you don’t need to know that since the tool below does that for you~) by executing the command below in the VS cmd:
gacutil -I "C:[PathToBinDirectoryInVSProject]\myGAC.dll"
YOU'RE DONE! You may now reference and use the shared assembly from all your applications, and whenever you want to update, just update the shared assembly.
Hope that helps!
You can create nuget resources, and use Nuget Server (Lastest version of teamcity support it) - and all updates w'll be handled by nuget.
Other approach is to create common folder and all project point's to dll in this folder (relativly) in this case you need to udate dll in one folder (after rebuild solution dll'll be updated automaticly)
Ofcourse you can allways install dll in GAC (Global Assembly Cache) this is handled by tool called gacutil.exe (in net is lot of example how to handle it).
I'm working on a object-oriented Windows API wrapper library, written in C++, and I have two projects inside the solution:
The actual library project;
A "test" project, where I write code that uses the library for testing purposes.
My goal is to be able to include and use the library header files on the test project, as if it was an actual project that uses the library.
I solved the file inclusion problem by adding "$(SolutionDir)" to the test project's additional include directories (is there a cleaner way?), but I'm struggling to get the test project to link. I get unreferenced externals errors, which I assume is because the linker can't find the DLL.
I'm completely lost here. I have set up project-to-project references, so that the test project is dependent on the library project, but that did not solve the linking problem. I couldn't find any option in either project's properties that seemed to be relevant to my problem.
Is there a way I can simply hit "Build Solution" and then run the executable?
In your project's properties > Linker > Input, there's a bunch of settings you can specify for the linker, such as, for instance, additionnal dependencies to link with (put the .lib generated by your other project there) and which paths to look for said libraries.
Let's say you have a class library project that has any number of supplemental files that also need to be included with the compiled assembly (e.g. simple text files or even a legacy unmanaged DLL that's wrapped by the assembly as an interop layer). While embedding the supplemental files into the assembly itself is relatively straightforward, we have situations where this is not possible or just undesirable. We need to have them as "sidecar" files (i.e. files alongside the assembly, potentially in subdirectories relative to the assembly)
Adding those files to the project with an appropriate value for "Copy to Output Directory" specified appears to be sufficient for projects that are completely self-contained within a solution. But if a separate project in another solution adds a reference to the assembly, it does not automatically pickup its sidecar files. Is there a way in the project to somehow mark the resulting assembly such that anything referencing the assembly will also know it needs to include the associated sidecar files? How do you do this?
You can use al.exe, but there also appears to be a C# compiler option. You want to create a multifile assembly using the /linkresource C# compiler option. Instructions are here, but the command is similar to this:
csc /linkresource:N.dll /t:library A.cs
Where N.dll is a native DLL that will go wherever the managed assembly goes (including into the GAC.) There's a very clear description at the link I provided.
Have you tried creating a setup for your solution ? There's an option of including sidecar files targeting to application installation directory.
Another option would be to include the sidecar files in the Assembly resources and un-wrap them to disk when run for the first time.
What if you create a merge module containing the library plus its dependencies? Your installer will then need to reference this module, but you will ensure all of the necessary files will be present.
Unfortunately there doesn't appear to be a lot of built-in support in Visual Studio for this, although I can definitely see the use case.
If you use Subversion for your source control, then you could link in an external reference as an externals definition. This would bring in the source code, and you'd be making a reference to the necessary assembly as a project reference instead of a DLL reference, and then the copy to output directory rules would come into play.
If that's not possible, another solution would be to include commands in the pre/post-build events of your in-solution project to copy the most up-to-date sidecar files from the remote assembly on a build. Of course this comes with the caveat that it doesn't set itself up automatically when you include the DLL in your project; you have to take manual steps to set it up.
I deal with this some time ago. Its a common problem.
You can create some postbuild actions:
http://www.codingday.com/execute-batch-commands-before-or-after-compilation-using-pre-build-or-post-build-events/
Hope this helps... :)
It appears to me that you're using the wrong type of reference. There are two types of references- Reference and ProjectReference. Reference is an explicit reference to a specific assembly. ProjectReference is a reference to another project (say .csproj).
What you're looking for is ProjectReference. VS and the default MSBuild targets are setup to do CopyLocal. If you set CopyToOutputPath true for your "sidecar" files, any ProjectReferences to this project now will also pull in the same files.
I'm not sure if you can to ProjectReferences across solutions in the IDE. I deal a lot with MSBuild where sln files are not relevant and this is how I deal with it.
What we did in our project is that we created as separate build file to do all those stuffs.
In your build file you can have tags to build your main solution, then add tags to copy files you need after build.
NAnt is also your option, but right now I'm happy using Rake as my build/debug automation.
Since this cannot be integrated within Visual Studio, what I'm doing is I create a task (either in MSBuild, NAnt or Rake), that executes vsjitdebugger.exe in the end to attach it to my Visual Studio when debugging.
These are just my styles for now, you can maybe create your own style.