I have a solution with my main windows application project and several class libraries. When I run the main project I would like to also automatically build the libraries as well (Which also have post-build event commands that need to be run).
I would like this to happen when I click Start and not have to press Ctrl+Shift+B first to build everything (because I sometimes forget and wonder why the changes didn't happen).
If you have referenced the assemblies in your main app, they should be built automatically. If you don't have references, you can manually define project dependencies via
Click right on the solution
Select "Project Dependencies"
Define your main app to depend on all the assemblies you need to be built
Dependencies will only be built, if needed, ie if no file changed since last build, it won't be built.
Related
I have two pairs of projects that I develop in NetBeans, both of which have a GUI project, and a library project, where the GUI project depends on the library one. In one of them, NetBeans recognizes that the dependency is local, and indicates as such with an Ma symbol, as seen below, with the dependency project in green:
This provides some nice functionality, most notably that the "Navigate to" (ctrl+click) functionality from the GUI project takes me to the source code in the library project. I also don't have to manually rebuild the library project for the GUI project to pick up any changes.
However, for the other pair of projects, NetBeans will pick up that the dependency is in my local Maven repo, but does not recognize that the source code is a Maven project that it also has open:
I've tried looking through all the right-click menu options, removing and re-adding the dependency from the NetBeans GUI, comparing the pom.xml, comparing nb-actions.xml, and nb-configuration.xml, but cannot find any explanation of why one library is recognized as local, but the other is not. The only information I've found online is at http://wiki.netbeans.org/MavenBestPractices, where it notes:
"Hint: If you open a project that other projects depend on, the icon in other projects changes to a "maven project" icon to denote that the IDE knows about link between the projects. However such a link is only established when the groupId, artifactId and version all match in the dependency and project declaration. Frequently occurring problem is that you change an API signature in your library project, but the application is not picking up. Often it's caused by the fact that the application is using an older version of the library artifact. The artifact icon can help you track down these problems."
However, I've verified that the pom.xml of the GUI project depends on the version being built in the library project, and even made the versions identical between the GUI project and library, and the "maven project" icon still doesn't show up.
Does anyone know how to debug this issue, or if there's a magic setting somewhere that I'm missing for how to make this link work? I've been trying with both NetBeans 8.2 and 8.1, and am compiling with Java 8 for both the successful pair of projects, and the unsuccessful ones.
Revisiting the project a couple years later, I finally figured out a way to get the dependency to connect locally.
Change the artifact ID of the dependency, and update the dependent pom to match the new name.
This is admittedly bypassing the root issue rather than addressing it, but given the inability to pinpoint the root cause, seems the best option at this time.
Actually, question was set in the Theme of the message. But yet again,
i have Solution with 3 projects, two of whitch are Static libraries and one is Application. How my Application project could know from where to pull these .libs.
Yeh, i can do it from Linker->Input->Additional libraries, but i think there are must be other way if projects are in one solution.
There is another way, works on VS2010 and up. Right-click your EXE project, Properties, Common Properties, Framework and References. Click the Add New Reference button and select your project that generates the .lib. Repeat as necessary.
This does two things, it takes care of the Additional Dependencies linker setting, automatically adding the output of the library project. And it ensures that projects are built in the right order, normally something you'd have to with the Project Dependencies command. In your given example, with enough machine horsepower, the library projects will build concurrently. And the main project won't start building until they are both done.
I don't understand the difference between these Xcode features.
I'm building and app - but the functionality of the app is being abstracted into libraries (so they can be distributed separately as an "SDK").
So I have a workspace of library projects and the app project. I can add library projects to the app project by doing "link binary with libraries". This gives me a list of .a library projects in the current workspace which I can link to.
I can also add frameworks here.
In the "target dependencies" bit all I can add is other targets in the current project.
What I really want to do is both - I want my app project to build all the other library projects when I build it. I also want to make it verbose what libraries the app (and other libraries) depend on.
So can somebody please explain the difference, and whether what I am doing is the right way to go about it?
Many thanks!
It says here...
Drag your framework product (located in the Products folder) to the existing Link Binary With Libraries build phase of your application
target. This causes the application to link against your framework.
And...
In the General tab of the inspector window, add your framework as a dependency for the application. Adding this dependency causes Xcode to
build the framework target before building the application target.
The build dependency you establish in the application target causes
the framework to be built before the application. This is important
because it guarantees that a built version of your framework will be
available to link against and to embed in the application. Because of
this dependency, you can set the active target of your Xcode project
to your application and leave it there.
So it seems that you're supposed to use both. Seems redundant though, because if you're linking to a framework then its a dependency. I suppose you might want to only link to a library and not build it first. Although Xcode seems to build linked libraries even without them being added to the dependency section. Perhaps that's a result of the "Find Implicit Dependencies" option in a scheme's build settings.
I do something similar and was explicitly setting the 'header search path' and 'library search path' in the final executable target. However this all depended on where the objects were being generated. Initially I had set this to be within the source tree (actually a sibling directory called build), however after changing the location of the Xcode DerivedData directory and telling it to build into that directory, the projects no longer built.
The final solution was simply to remove the explicit setting of the 'header/library search path' and set the target dependencies correctly. This resulted in the project building for debugging and archiving without issue.
I'm using Xcode 4.3 to create a framework for OS X. I created a workspace and a project (with a framework target) to go in this workspace.
Now, I want to include & link with a third-party framework which I've also added to the same workspace (but not within my project). I clicked the + button in the "Link Binary With Libraries" build phase, and the third-party framework simply appeared in the list of available libraries.
The linked framework shows up red in the Project navigator, as the third-party library has not been built yet (confusingly, though, my project successfully builds — although I'm not yet trying to use the third-party framework):
I was going to solve this by adding it as a Target Dependency, but when I click + on the "Target Dependencies" build phase, the third-party target doesn't show up in the list.
How should I properly configure/resolve this dependency? Also, do I need to create a Copy Files build phase to ensure the framework is copied into my target's Frameworks directory? How would I set that up properly?
I ran into something similar but with static libs.
Do what you did to build the framework, build your app (even if it fails, the framework should build)
Remove the reference to the framework in your app target's link build phase
Locate the built framework in the Finder (the one built by your app workspace).
drag/drop it into the app project that uses it. Notice that this time it appears with black color (not red)
click it, and make sure the Xcode inspector shows "relative to built products" (you may need to change it reference type), and that the path is just the myframework.framework.
check that it has been added to the app link phase (it should)
that's the one you can use in the copy/build phase.
I have a project which is under source control using TFS. Actually, I have 2 solution in one TFS Collection. suppose the first solution is called SolutionA, while the second SolutionB. Each solution has it's own project in TFS. Now the problem I have is that, one of SolutionB's project should reference an assembly which is build in SolutionA. So what's best practices to achieve this?
Thanks
You have SolutionA that contains ProjectA, and SolutionB that contains ProjectB:
The two easiest approaches you can use for referencing ProjectA from ProjectB are:
Simply add ProjectA to SolutionB, and then ProjectB can use a project-reference to ProjectA. This means that you share the source code for ProjectA and make an independent build of it from within SolutionB as well as SolutionA. This will slightly slow down your SolutionB build (as you now always build ProjectA in it), but will allow you to make edits to the source code for ProjectA, and treat it as a normal part of SolutionB.
Build SolutionA and use a post-build step (or redirect the output path) to save the resulting ProjectA assembly (and its pdb and xml files, if you want to be able to debug into it) into a shared folder (e.g. C:\Libraries). Then use a file-reference from ProjectB to C:\Libraries\ProjectA.dll. This keeps your SolutionB build fast, and removes the need to have the ProjectA source code lying around, but means that any changes to ProjectA require a double build (first SolutionA to create the .dll and then SolutionB to pick up the changes to the .dll). (You can also opt to check in C:\Libraries to source control so another team could just provide a pre-built binary for ProjectB rather than you having to have anything to do with SolutionA yourself)
To clarify what I mean by Project-references and File-references: In your Solution explorer, right-click on the project's References folder and choose "Add Reference...". In the dialog box that appears, you can choose the tab "Projects" to list the projects in your Solution, and reference one of them (a project-reference). Or choose the "Browse" tab to browse to find a pre-built assembly .dll file (a file-reference)
(You could also install the assembly from ProjectA into the GAC, and then use the add reference dialog to reference it from the ".NET" tab, but IMHO this is a more complicated approach to use as you have more mess to clean up to remove the dll from your system)
There are a couple of options.
If the same team manages both solutions, I would highly recommend just putting them both in the same team project, Or just sharing the same source repository between both projects.
If they are managed by different teams, it might make sense to just give solution b a binary copy of solution a, and update it when a does a release.
If neither of those work, you could add a custom msbuild script in solution b which will get the latest version of solution a from source and build it, before building b. Something like this
My personal opinion is that team projects tend to get over used. I like to just have one team project per team and put all code in the repository there.
Guys, I found a better solution. When I create SolutionB, then I just add ProjectA in SolutionB without branching. To do that, just click File -> Source Control -> Add Project From Source Control.
Voila :-)