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.
Related
My team has built a Xamarin.Forms application using VS2017. We are using a Shared project because one of our core functionalities requires ESRI mapping, and ArcGIS Runtime for Xamarin does not support anything but Shared projects at this time.
The next app that my boss wants should be fairly quick to develop if I can use the existing code we've already written for the first app. However, I don't see any way that I can reference that code from another project. I have tried adding a new UWP project to the existing one, but then I have to add all the same NuGet packages, 90% of which are unnecessary to this new project. On top of that, it won't actually compile correctly since the App.xaml is different.
I've searched all over trying to find a solution to this, and haven't come up with anything. PCL is not an option, nor is .NET Standard. Is there any way to accomplish this?
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.
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've been writing C/C++ for years using Xcode and am very comfortable with *nix systems. Now I'm working with people who only understand Windows; I've decided to try to learn that environment too.
I was thinking that google would be my best friend, but even the terminology for VS is sufficiently orthogonal to that of Xcode that I can't make any headway. (E.g., what's the equivalent of "Add new Target to project" for VS?)
Can anyone point me to a guide to VS for Xcode practitioners? I've seen lots of translators going the other direction.
Thanks!
I do not know of any XCode to VS Guide, but according to XCode Documentation:
A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace.
The analogous concept in Visual Studio would be a project. In Visual Studio, a project contains code files, assets and settings which compile into an output of some sort. (Could be an executable, a DLL, a website, or a few other options...) Projects can reference other projects or other external libraries (System or user libraries) which are all delivered together at compile time.
A solution contains multiple projects which can be related (referenced) and compiled and linked together.
When you first start VS, it will ask you to Open or Create a project. It usually will automatically create a solution and automatically add the project to it. To add additional projects, you can right click the solution in the "Solution Explorer" and add another project.
Hope this helps
I believe what you're looking for is the Build Configuration Manager in Visual Studio. (It's been a while since I've used XCode). As I recall a "Target" in Xcode is how you want the project built. In VS you get a Debug and Release configuration by default but you can use the Build menu and choose "Configuration..." to create more.
I don't know of a tutorial for XCode users but Kate Gregory has some nice beginner screencasts on pluralsight for using Visual Studio 2010. Those may get you over some learning curve hurdles. I think they have a 30 day free trial. If you move on to .NET development they have a lot more that can really help you get up to speed quickly.
Quick Terminology
In Visual Studio you typically create a Solution. A solution can consist of any number of Projects. You can add projects for .DLLs (libraries), services, applications (gui and console based). You can have multiple applications but can only designate one as the Startup Project.
In my typical project I start with the GUI and Add a project of the type I want. Then I often add a library project for new code that I think I can use across multiple applications. Existing code in both supplied libraries and ones you've built are added as References. You can right-click on References in the Solution Explorer and select Add References.
In XCode (when I used it) your IDE consisted of two pieces, XCode and Interface Builder. In Visual Studio you can build interface elements directly in Visual Studio ( but there is also a tool called Blend that allows for UI creation and modification). There are THREE major types of interfaces web (usually an ASP.NET application), WinForms and WPF. I think of WinForms as the equivalent of what you build in IB. WPF is the most recent addition and has lots of advantages but a somewhat steep learning curve.
This is probably oversimplified because VS does so much and I'm mostly familiar with the C# and C++/CLI capabilties. However it also supports Visual F#, Iron Python, Iron Ruby, Visual Basic, Sharepoint, Office Integration,Silverlight, XNA, etc.
Visual Studio is very extensible. There are lots of extensions to make it integrate with other tools. There are also a couple of extremely useful extensions that make refactoring and writing code easier, my personal favorite is ReSharper from JetBrains.