We have a .NET 4.0 solution which contains a Fortran 95 for Windows project whose output is a managed DLL. The solution builds a Winforms app which uses this managed DLL.
The Visual Studio plugin which supports the .ftn95p project type is flaky at best, for example, it uses absolute paths to source code files which have to be fixed up in a pre-build script - which causes its own problems to do with project file reloading - all sorts of modal dialogues get thrown during the build, which is no fun for a developer who doesn't need to ever touch the Fortran source.
I am trying to think of ways to smooth out the process of building the solution on a clean machine.
I have built the Fortran DLL manually, and added a reference to it where required in the other projects, removed the Fortran project entirely, and everything works perfectly.
However there are some developers that will need to have the whole solution, as it is now, with the Fortran project loaded into the IDE.
I am looking for ideas on how we can better support both classes of developer:
those who need to touch the Fortran (who will just have to continue putting up with the flaky build
those who never need to touch the Fortran (who would benefit from never having to deal with the Fortran plugin's weirdness)
I have already considered two solutions, but there are maintenance/sync issues there. Could we leverage Build Configurations in a clever way? I can't think how, but it's a possibility.
Related
I work on a large system (10+ EXEs and 50+ DLLs). The entirety of this system was written in C++ up until around 2005, when we began migrating components to the .NET framework.
It would help our migration efforts tremendously if I could switch individual DLL projects to C++/CLI and provide both a legacy unmanaged API and a new managed API into the same DLL.
This approach worked when we first started, but then broke soon after. Visual Studio does not appear to support two C++/CLI projects linking to each other via the unmanaged API.
Is there any way to get this to work beyond the brute-force approach of adding export libraries from one project as content to another? That's what project dependencies are supposed to handle already.
Perhaps #pragma comment in the native header files would be useful. For that to work you need each project configured to write its generated import library into a common area that can be added to the library search path, but it saves you from having to manually add lib files as linker inputs, or as project content items. Also, it makes keeping release and debug library versions separate more easily, since you can just have a different search path for each configuration, instead of having to add each individual library twice to every single consuming project.
I have a project, which works fine in VS-2010. And runs fine.
But I want to create a make-file by using Omake. How to build the same in Omake.
I have gone through all the documentation of Omake, but it does not say how to make it.
My VS-2010 project contains .c, .cpp, .h, .rc MFC and many subdirectories too.
There is no direct way to convert a project from VS to Omake: you have to write the 'OMakefile's by hand since the two build systems (MSBuild is behind VS) and concepts are somewhat different. Once the OMakefile's are working, you can always create a Visual Studio project of type "Makefile" that calls the omake utility behind the scene.
If the reason for change is that you want to make the projet multi-platform (well, I doubt so since you use MFC), you may consider CMake, a widely-used project generation tool. CMake can generate both Makefiles (GNU) and VS projects, depending on the platform, from a project description.
I have a Visual Studio .Net Solution which has many projects/libraries.
When I work locally on my own PC there is no problem as I tend to recompile those libraries that I have just changed and everything is in sync.
The problem is sometimes other developers who once in a while require to work on or look at my code have an enormous problem recompiling everything.
In the configuration Manager, I do not have all projects checked else it would take too long to build everything whislt working.
Problem is when the solution is compiled on another application, some of the errors reported say a particular library has error and its taking too long to figure out all the dependencies compiling each one individually.
Even when checking everything in the config manager it still does not seem to compile correctly.
I thought when you add a reference to a library the dependencies are taken care of.
Is there a simple way to make sure the solution determines what are the correct dependencies and make sure everything is built in the correct order?
Thank you
After other developers got new source codes from you, they should close Visual Studio and reopen the solution.
Sometimes there are also troubles with dependencies in Visual Studio. First, try these menu commands:
Build > Clean Solution
Build > Rebuild Solution
This will show you which dependencies are cyclic or not correct.
Also, in Visual Studio project must not depend on another one which creates executable (at least for our pure C++ -written project this is true). I.e. "Utils" project which compiles into "Utils.dll" cannot depend on "MyApp" project, which exports some functions or symbols and compiles into both MyApp.exe and MyApp.lib (or some other kind of assembly). If you have such a dependency, you must correctly setup project build order and manually set MyApp.lib as in linker inputs.
You can package and distribute your assemblies using http://nuget.codeplex.com/. It's made to solve this problem.
In short: is there a way to compile and run single file in NetBeans or Visual Studio without having to setup and tinker with projects?
I'm currently using code::blocks as my IDE. It's fast and very simple: perfect for my needs as a begginner.
I wanted to dive a little deeper and try out a more advanced IDE such as NetBeans or Visual Studio. It appears I have to mess with projects and have a setup that seems overkill for having to compile and run one very simple .c/.cpp source file that contains less than 50-100 lines of code etc.
Is there a way around this?
You always have to setup a project - this is where information about libraries etc is found by the IDE, so it cannot do without. If you just have one file, and not a lot of dependencies you could just stick with a plain editor. Once you want auto completion of functions, refactoring, etc... you have to store the information about what is relevant somewhere, and the some sort of 'project' will become necessary.
Is there any tool that can convert a large and complex* Visual Studio 2005 (or 2008) Solution into a SCons project?
* Lots of projects and multiple configurations on multiple platforms/compilers
Probably not, and even if there were, SCons gives you significantly more transparency and flexibility about managing your build than visual studio does. As a starting point, it's best to do each one in turn.
Create a new makefile project
Clone the source from one project to another
Invoke scons from the makefile command.
Replace the dependancies on the old project with the scons version.
Test
Repeat from 1. with each project.
Once you've done a few projects, it's pretty easy to refactor the major differences between build types (shared libs, static libs and programs) and platforms into a module of common scons helpers that can be imported. On windows, consider groups of flags for things like debug and release builds, standard library linkage and exception handling.
Also, things to look out for include:
If you're doing cross platform builds, consider the differences between the linking models with respect to the effects of missing symbols.
What you'll do to deal with manifest files and invoking the visual studio tools.
Variant build directories (debug/release) can be tricky at the start. Start simple, and enhance your build once you're sure it's necessary.
The following script looks promising. I may give it a whirl: the reason the by hand solution isn't completely practical due to the sheer scale of the solution in question: it has hundreds of projects. This is why I was thinking a script that would generate SCons modules would give me a starting point.
Unfortunately porting the solution in question to SCons by hand would be a project in itself!, although I do admit it would be the 'correct' way to do it.