Xcode - Project References vs. copying .a file - xcode

I've been developing for iOS for over a year now, and in the last few projects, I've been using other projects, such as RestKit or SSZipArchive to name a few. When doing these projects, I would include these projects as cross-referenced in the workspace underneath my main project.
What I find baffling about the process is that this is unlike any other language that I have encountered. Normally, in other languages, I take compiled output files from a project (.dlls or .jars, for example) and those are included in a project. I know that when you build a static library in Xcode, the resulting file is a lib*.a file.
What is the reason for keeping these projects cross-referenced as opposed to just copying the lib*.a files into the project?

What is the reason for keeping these projects cross-referenced as
opposed to just copying the lib*.a files into the project?
Sounds like you're talking about adding the library project as a subproject. The reason for doing it is to set up a dependency between your project and the subproject. If changes are made to the subproject, Xcode will rebuild your main project so that the newest version of the library is incorporated.

Related

Why Visual Studio makes duplicates of .dlls in build folder?

I work on the project that I have inherited from another developer. It is mix of VB.NET & C#.
Solution is made of multiple projects: Config(start-up project),Common,Agent + project StdPlugin under Plugin folder. (Plugins are .dlls that are loaded during runtime).
For non-plugin projects, output path is set to bin\Debug\. For Plugins projects output path is set to Config\bin\Debug\Plugins.
After the project is compiled, Config\bin\Debug\ has all .dlls +.pdbs and .exe for all my projects. However, Config\bin\Debug\Plugins also contains copies of all project .dlls + .pdbs and .ddl + .pdb for StdPlugin project. In other words, I am getting duplicates. On top of that, when I run Build->Clean Solution, Config\bin\Debug\ is being cleaned out, but Config\bin\Debug\Plugins is not.
Some clarifications: 1. Project is build for debugging. 2. I noticed above issues while investigating The source file is different from the module was build issue that affects the Reader project. It would not stop on breakpoins in Reader project.

Conflict with VS project dependencies and lib files

I have a big VS2008 solution containing >30 VS projects with legacy code. One of these projects (let's call it A) generates a header file, which is needed by a few other projects (for example B). When I go to "Project Dependencies" of the VS solution, I can check project A for project B's dependencies - but VS includes in the project B's linker command line options an additional argument for project A's lib ("A.lib"). Unfortunately, since project A does not create a lib file, this project B will never find one and cannot be built.
Is there a feasible solution for my problem?
Thanks in advance!
Cheers,
Chris
You should set Ignore Import Library in project A.
This option specifies that the (import) library generated by this configuration should not be imported into the dependent projects.

VS2010 C++ how to have different project references for each developer

We are trying to move from C++ VS2005 to VS2010, but can't figure out how to move from the solution dependency model to the MSBuild project reference model. We have multiple developers, but don't distribute all the source to each developer although each developer is provided with all the header files, .lib, and .dll files.
With VS2005, each developer has their own solution and sets up a project dependency to a project, unique to that developer, which includes all the .lib files they don't have source for. This way, they can use the most current .vcproj files for the source they do have.
In trying to move to VS2010 / MSBuild, the project files now require that dependencies be included as references, yet some developers will not have a copy of the referenced project, only its .h and .lib.
Is there any way to combine the solution-based dependency model of VS2005/VS2008 with the MSBuild project reference model of VS2010?
MS removed implicit adding libraries in linker list once dependency added.
Now libs should be explicitly specified in Additional Dependencies of linker settings as well as includes in settings of compiler.

Make Visual Studio not to compile any projects

Is it possible to tell VS not to recompile some projects every time and use already compiled dll-s instead?
You can exclude any project from building in Configuration manager. Just unselect desired projects in Build column. You still will be able to debug those projects.
Instead of project references, you can add the compiled DLLs as references.
Any such referenced project will not rebuild if not changed.
However, since the references will now be to DLLs, you need some strategy to keep them synchronized and up to date with your code.
As I understood your question, you have a solution with multiple projects and you seem to have dependency of some of them on some other.
VS will always compile all the "loaded" projects. But when you add a reference to a project, add it directly to a (preferred) DLL assembly file, and not to one of the projects. This way the other project will be compiled but you are referencing the same DLL assembly over and over. Since if you reference the project, the output of the project is always what you reference actually.

Best practices organizing a Visual Studio solution

I need some help regarding Visual Studio solution and project organization.
I have a solution with several projects. All of them are written in C# and are compiled as libraries to be used by the GUI. Some of these libraries have also dependencies with others. For example, TestExecutive needs LoggingFramework, Communications needs LoggingFramework too.
Which is the best way of organizing? I'm thinking on a folder assemblies to hold libraries' binaries in one place. Something like:
Solution
|
|-- TestExecutive
|-- LoggingFramework
|-- assemblies
There is also another problem. One of the projects uses a native C dll. Where do I have to place this library? With the librarie's assembly or with the final executable?
EDIT:
Ok, now suppose I have the WinForms program running. I have source code and binaries mixed. Which features do I need to generate something I can distribute? I mean, with all the libraries and configuration files, but without source code. I have done this before with Nullsoft installer, but I don't know if visual studio can help you doing that.
A few things here:
When one project depends on another, you can set up that dependency in Visual Studio. Right click on a project and select Project Dependencies...
For other .NET assemblies that are NOT part of your solution (3rd party tools, etc.) I do exactly what you showed here -- I have a separate folder parallel to the projects. Then I set up the assembly reference in each of the projects with "Copy Local" set to true and it works fine.
For native C dlls, it's a little different. There is no direct reference to them in the references section of the solution explorer. The compiler isn't going to look at the dll to check your p/invoke references or anything like that. You just need to make sure the dll is part of the deployment on your top level web or winforms project. It's a content file just like a css file or image or something. Just add it as a file in the project and make sure the "Build Action" is set to Content so Visual studio knows to just copy the file as part of the deployment
I set my solution folders up a bit differently than you. At the top level I have the following folders:
\build
\lib
\src
The build folder has build scripts (NAnt, MSBuild, etc). Any 3rd party assemblies (or anything I'm not building in the solution) get put into the lib folder, in an appropriate sub-folder. For example, I'll have log4net, NUnit, RhinoMocks folders in the lib folder, each containing the files needed for that dependency. The src folder has the solution and all project files.
I like this structure because it clearly delineates between the project code and the other stuff that is required by the project. Also, I usually set up some custom build tasks to copy the resulting assemblies for my project into either a \deploy or \lib\ folder. This way you don't have to hunt in the \src\\bin\\ folder to get a built assembly or the whole project; however this seems a bit beyond the scope of your question.
Btw... I didn't come up with this structure on my own, I think I started off using Tree Surgeon and evolved my process from there.

Resources