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.
Related
I am developing an application (exe) in c++ with visual studio. I am not that experienced. Now, I came to the conclusion that it might be better to compile the general program functionality into an lib or dll file, which I then would use in a different visual studio project, where I basically implement the functions from the lib files for the more specific purpose of my project. With my current setup, I get the impression that I am starting to mix the gerenal functionality with the specific problem statement.
Basically I am asking for a way to convert my current full visual studio project into two separate projects, one for the gerenal lib files representing the classes and program modules, and one for the specific problem implementation. Is it possible to also keep everything in one visual studio project (edit: solution) for convenience?
I have a situation where a class library project is used by multiple other projects in Visual Studio. While working on one project sometimes I may have to make changes in the shared code that is relevant to one of the other libraries. These changes may break something in the other class libraries until the necessary work is done to bring all other in line with the changes in the shared library.
The question is, how do I share the library and reference specific versions in the other projects?
If these libraries are source controlled, then whenever you want to compile a library that depends on your shared library, make sure you checkout the appropriate version of the shared library.
If these are .NET libraries, you could install the different versions of your shared library in your GAC, and have your dependent libraries reference the appropriate version of the .dll directly. Of course, you won't have the advantage of being able to change the shared library within the same solution as your application because it wouldn't be a referenced project.
Alternatively, instead of installing them in the GAC, you could keep a common directory with your versioned shared libraries (see the answer to this post: Visual Studio: Add same project or reference to different solutions).
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.
I have a somewhat odd problem that I don't seem to be able to get to the bottom of. We have a mostly unmanaged C++ application that's been around for a while and thus has been built using lots of different versions of Visual Studio, with it being updated to the current version of Visual Studio on a regular basis.
I've now run into the following issue:
In VS2010 I've added two new projects to the existing solution. Both new projects are DLLs, one built in plain unmanaged C++, the built using a mix of C++ and C++/CLI and is thus built with CLR support (/clr). The second C++/CLI DLL should be used by several other components of the system
Using Properties -> Common Properties -> Framework and References, I add the two new DLLs as a dependency to a third DLL. The third DLL is doesn't know anything about .NET and is implemented in pure native, unmanaged C++. The new DLLs show up correctly in the dependency settings and the new references work in the sense that the build order of the solution is affected (correct), but for some reason, only the import library for the plain native C++ DLL is added to the linker command line for DLL that references both libraries. The second, mixed library generates an import library, but VS2010 doesn't add the import library to the linker command line which predictably results in several unresolved external symbols.
The one setting that appears to trigger this behaviour is building the DLL with Common Language runtime support as all the other settings of the libraries are identical.
I currently have a workaround for this issue - I simply add the import library as a manual dependency - but I was wondering if someone else has encountered this problem and if there is a way to get make this feature work as expected without the workaround?
My background is c#, .net, and Visual Studio.
I've been trying to get to grips with Cocoa development, but am finding it hard to find information about certain things, maybe because I'm coming in from a Visual Studio perspective.
A few questions:
What's the difference between a "Framework" project, and a "Library" project in XCode?
What are the consequences of choosing "dynamic" or "static" for your project when starting a new XCode project. Can this be changed later on? does it affect the contents of the project?
Does XCode have the concept of a "solution" with various projects like Visual Studio? If so, how do you reference projects with each other which are in the same solution in XCode?
Is it even right to approach a Cocoa project in the same way as a .net one. For example, if I was going to build a simple image manipulation app, I'd start with the core library, which could be referenced in a winforms, silverlight, or an MVC frontend app. How does that organisation work in XCode?
A Framework project builds a Framework, and a Library projects builds a Library. A Framework (.framework) is the means by which a library and its associated header files are bundled together in one package (similar to the way an executable and its sundry files are bundled together into a .app package). If you're building a library which you intend to use in multiple Cocoa projects, or distribute to other developers for that purpose, a Framework is probably the most convenient way to do so.
A static library (.a) is analogous to a .lib file in Windows. It's compiled code which you can link into your executable. A dynamic library (.dylib) is analogous to a .dll in Windows. It's compiled code which can be dynamically loaded by your executable. You can change the output from one to the other after you create it (see the Mach-O Type field under Linking in the Build tab of Project Info. However, there are probably other settings which would vary between the two. My advice would be to decide which you want to make, make the project for that, and don't change it.
Yes, you can build multiple things from an Xcode Project. An Xcode project is exactly analogous to a Visual Studio Solution. What Visual Studio calls Projects, Xcode calls Targets. So an Xcode project can have multiple targets. Say, one for a Framework, one for an application that uses that framework, one for a suite of unit tests, etc. Make yourself an Xcode project, and right click Targets->Add->New Target, and you can play around with it. Each Target has its own build settings, files, etc.
My background is more the MFC/C++ side of the Visual Studio house than the .NET/C# one, but to my knowledge, what you describe is possible, even desirable, in Xcode, sure. My projects have thus far never been large enough, nor the code amongst them common enough, to bother having a separate library for core functionality, but there's no reason you couldn't do that.