Let's say I've got an existing .NET assembly built in Visual Studio 2010, which is consumed in some other Winforms product. It has no third-party dependencies.
I want to reuse that library directly in a MonoTouch solution.
As it stands, to be able to add a reference to my library from within my MonoTouch UI project, I have to create a new csproj file and create links to all of the source files within it.
This works but is a maintenance burden. There must be a better way?
Thanks in advance.
As of today you need to rebuild your assemblies. That's because they'll be linked to monotouch BCL (e.g. a different mscorlib.dll) which a superset of the base class libraries (BCL) shipped with Silverlight.
Hopefully newer release of MonoTouch (and Mono, Mono for Android...) will support the new "portable library" which would make it easier to share compiled binaries across frameworks.
http://blogs.msdn.com/b/bclteam/archive/2011/01/19/announcing-portable-library-tools-ctp-justin-van-patten.aspx
Believe it or not, you actually can reference a .dll lib built in VS.NET as long as your shared assembly is not referencing any other assemblies that would make it incompatible with monotouch. I currently am doing this on our project. The referenced .dll only has dependencies on System and System.Core and its basically just a set of POCO's. I'm sure someone with better knowledge can tell you exactly what it would take to make the .dll incompatible. Even using an incompatible API call within System or System.Core could break it per poupou's answer but if you keep your shared .dll dead simple it should work.
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 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).
I'm trying to make a portable class library in VS2010. By default, it seems to be targeting .NET Framework 4 and higher. I need to target 4.03 or higher because I need some features that were added (System.Xml.Linq). But when I try to change the target framework, the change doesn't work. I get this dialog:
I can choose one of the other frameworks and say OK, but when I look again, it's set back to the same Framework 4.0 setting, and my code using the 4.03 features still doesn't compile. What's going on here?
Update: It does let me choose 4.5 as long as I don't choose Mono for Android or VS Mono Touch. It looks like something in those libraries requires 4.0, but I don't understand why, since 4.5 is backwards compatible. And this is for use in Mono, so I need those.
I figured this out with some hacking of the configuration files for the portable framework. First, read this post about how to add library support for PCL's for MonoDroid and this one to do a similar thing for MonoTouch.
In the .csproj file for the PCL project, I found this line:
<TargetFrameworkProfile>Profile95</TargetFrameworkProfile>
which points to this folder:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile95
In that folder, there's a subfolder called SupportedFrameworks and this was missing the magic files MonoAndroid,Version=v1.6+.xml and VSMonoTouch,Version=v1.0+.xml. I added these, as described in the linked post, and now it works.
I've implemented the ability to pick and choose the PCL profile constraints in MonoDevelop in git master, but it has not yet been released.
I believe these features will be included in MonoDevelop 3.1.0
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.
I've downloaded the Ninject SVN visual studio project and I want to compile it against Silverlight libraries to make a Silverlight compatible DLL.
Is there a setting to change somewhere to make it a Silverlight library project, or do I need to swap in and out references here and there?
There is no setting, you will need to swap in the appropriate SL libraries, its not just "here and there" its actually "everywhere". You then need to hope that the project doesn't use anything that isn't present in the SL libraries.