Although I searched a lot for Eclipse & Android development in a team
methodology, I was not able to find a clear suggestion of a correct
way to configure Eclipse and source control environment to work nicely
together.
I am a C# developer, and on Visual Studio everything is layed-out
nicely:
You Have a solution file (xml) which contains a definitions for
the projects and their relations and configuration, in addition each
project has its own configuration in a project definition file (also xml). You check-in to source control all the sources and the
projects and sln file (the configuration files) and for each new
user you just have to checkout (clone) all the files and compile the
solution locally - everything is already configured, all you have to
do is double click on the solution file and rebuild the solution.
If you have any other dependencies (dll files)- you just add them to
your project (could be folder in the project or common folder for
several project) and reference the required dll from the project
definition, and commit (push, checkin) all the dlls` as part of you
source control.
In Addition a solution have virtual folders where you can group
several projects together in a logical manner with no technical
implications.
In Eclipse and Android specifically - everything is different
and mostly not comfortable or logical at all.
You have a workspace with projects - where workspace is
not really a solution and its .metadata files are truly
meant to be local and should NOT be checked in to source
control. What to check-in from an Eclipse workspace .metadata
So you have no solution level configuration to check-in to source
control. (Checking out projects and importing them to a workspace and
reconfigure everything per client is not reasonable) The only solution
I found for that was Projects Set which I have to update manually
each time I add project to the workspace (export the project set to a
file and commit the changes to the file manually) and in addition this
concept ties me to the source control (In visual studio I can copy a
solution folder with its projects sub folders and dependencies folder,
zip it and send by mail - and everything will work the same). How to
organize “projects” and “solutions” in Eclipse? Project Set
File Team Project Set
In addition to that in android - for example when using Google play
services, the suggested way to reference their lib (jar file and some
resources files) is to copy google_play_lib from the sdk and reference
the project itself (that is due to resource which must be compiled to
your apk file), this means I have to add the google play lib project
to my source control - which seems a bad thing to do. References for
that: Why do Google recommend copying libraries into your tree?
should I check in the Google Play services library project to source
version control for GCM support?
So I am kind of frustrated here from eclipse configurations for
android and source control management (especially compared to Visual
Studio).
Would love any team configurations and source control management
tips/tutorials for Eclipse and Android development.
Thanks.
I just started developing in Android and I spent 2 days looking into this topic. Below I will summarize what I found on this topic.
Required tools
Eclipse
ADT Egit - eclipse plugin used for the source control
A remote server to store your
git repository -> You can have a look at Github
Git flow - workflow methodology that can be applied in Git - Check this site for details about how to implement the workflow in Git
You set up a Git repository on the remote server where everyone from your team has access. The git repository can contain anything that the project needs. Resources, assets, source code even additional dependency projects your app needs(Eg. Android Support Library). I recommend creating not storring in the repository the binaries like the apk files, because they change very often.
If someone from your team wants to work on a feature, he or she creates a local copy of the repository(clone). On the clone, it creates a branch for that feature and starts developing the feature. Once the feature is done, it will be merged on the main development branch and pushed to the online git repository. If you use the git flow method, you can have a dedicated integrator making periodic releases from the development branch.
With egit you can import in Eclipse only the projects from the repository you work on. Check the User Guide to get an idea on how to do that
I hope this helps :)
Related
I am currently working on a personal project but I want to use Azure & Visual studio online build facilities for self teaching purpose. I am having a hard time resolving this problem :
I have a wpf app connected to an azure web api.
Wpf app is in its own Git repo, web api is also in its own Git repo.
Since both apps shared a common model, I put common model in its own repo as well to avoid code duplication.
I must be missing something ....
What I want to do
When I build on Visual studio online, I want to build "common" and feed its output dlls to webapi and wpf apps so that they can reference the model.
Solutions considered so far
nuget package
making a nuget package of "model" but where do I push it ? It's definitively not going to be of any value to nuget.org so no go.
I would need some private nuget repo in visual studio online, not sure it exists.
postbuild event
I also considered adding a post build event to the "common" build and copy its bin*.dll output to wpf and webapi apps to some "dependencies folder" but I find this dirty, Moreover I am not sure a build can push its output to the input of another build (I know Jenkins can but I am unsure about visual studio online), Moreover, how can I reference dlls which do not exist yet in my csprj ?
commit bins in repo (ugh)
Of course, I could build model locally and push the resulting dll in the git repos but, well, I am against putting binaries in versioning tools :)
Change my design
Consider that WPF only needs dto and not the real entities (which is true) but webapi will need to deserialize dtos anyway so back to square one, but with dtos this time :)
Thanks for your input !
Thanks a lot to CrowCoder !
That's exactly what I needed : using the "Package Management" extension in visual studio online, which is free up to 5 users.
Steps required :
configure nuget on my local machine,
create the nuspec,
create the feed,
package the model library
configure the build to push the library to the feed
use nuget packages to reference model
I'm trying to get our SVN and TFS repo structures finalized for a new mobile project we are starting. The code is in 2 (or 3) sections:
REST/Web API/service for all database interaction
The "web" code, which consists of css, html, js (and Angular) etc
iOS project...Phonegap/Cordova code
I've already created a project on our Jenkins (iOS) build server and have that configured to build the iOS source code, create an IPA file, and upload to TestFlight for the testers. I also have created a TFS repository for the REST/Web api code that is building successfully, I'm just waiting for my permissions to deploy this code.
So, as you can see, lots (not really) of moving parts to this application. The problem that I have now, is that there is code that is technically "shared" between the iOS code and the Web (service) code, which is all of #2.
I've read about svn:externals, but obviously that is for code that is encompassed COMPETELY in SVN (I think). How can I accomplish #2 to work with both source control systems?
Edit: I am restricted to using SVN and/or TFS for source code repository.
Use Visual Studio Tools for Git (2012 or 2013) and switch all development to git? This also allows you to setup TFS 2013 (or Visual Studio Online) as your git server should you want to. Or use svnBridge for TFS and see if you can get that to work with the svn:externals (never tried that angle before).
You could also use git svnand git tf in combination with local git submodules in a local git repository (but store the remote masters in tfs and svn respectively), but that's making things more complex than need be.
And you can also use a build system to generate a NuGet package and reference that from Visual Studio/TFS, that way you'd have a single source for the package (hence easy reuse) and each application can be built in its own ecosystem.
And you can always install AhnkSvn or VisualSVN and store all the Visual Studio stuff in Subversion too.
So I have a solution which contains 4 projects, a "Core" Project which is the actual application (as a class library), and 3 wrapper projects, "Console", "WinForm" and "Service" which basically wraps a Facade class in the core class and contains various settings to handle different logging strategies for each different application (Console/Trace/File) and launch the application as either a Console, WinForms or Service, depending on how the customer wishes to deploy the application.
In the Core project I have 3 resource files which contain simple template views for the Nancy web framework. However the way Nancy looks for these views are on the current path. Since the files in the Core project aren't on the current path for any of the 3 other projects I need a simple way to access these files across projects.
Somewhat naively I thought this was where the concept of a "Solution" came in, to handle dependencies between projects. However by searching the Internet, much to my surprise, it appears there is no elegant way to do this. The only two solutions I've been able to find involves copying the files to a scratch/temporary or directory in the solution, and copying them to the respective needed directories later, as post build actions, and Adding an item manually using "Add as Link". Now while both these solutions technically work, the first leaves (possibly out-of-date) build artefacts lying about where they don't really belong (IMHO), and the second is tedious, time-consuming and prone to human error (because you can't just link to a directory).
Are these really my only two options, or is there some third, totally obvious way I've just missed because I'm new to Visual Studio?
You could use a custom IRootPathProvider in Nancy, if the only things you need are Nancy specific.
The other option is to link a folder - you can do this, but it involves manually hacking on the csproj file, there's a few questions on here about it, including this one:
Visual Studio Linked Files Directory Structure
Nuget is a package management system, that I have used to share artifacts between projects as dependencies. You could include libraries available via nuget.org or have your own nuget packages defined.
Teamcity has got good support for generating nuget packages with every build and can serve as a Nuget server.
Here is a reference to include files into a nuget package.
i wanna deploy a C# Windows Application project using Setup and deployment project technique
but i don know what should i use
after i open File > New > Project > Setup and deployment > ....
then what ,, what should i do next
In the past I've used the Visual Studio Setup Project or Innosetup for my programs. I prefer to build .msi's over exe's so Visual Studio Setup Project has been my goto for a while now. It is however, very lacking in capabilities. The interface is not intuitive either in my opinion. Every time I build an installer there is a lot of trial and error install/uninstall to get it right. Other's have pointed out WIX and I've looked into it. It appears to be very flexible and since it is open source, we should be able to count on it for the long term.
Here is a recent article about WIX. What I found interesting is the article claims (see link in article) that Visual Studio Setup Project is being End Of Life'd in VS 2010 + NEXT_VERSION. This is a little disconcerting to me. Since I don't want to begin to rely on the new Install Shield "Lite" in VS, I'm going to put effort into learning WIX. I hope it'll pay off in more flexible builds for my applications as well.
All that said, when creating a VS Setup project, I usually use the wizard to put in the initial plumbing. You'll point it at the files you want in the .msi. Typically for me this means the "outputs" of one or more programs in my solution. Any managed assemblies referenced in the programs will automatically get picked up as dependencies and included. Unfortunately unmanaged assemblies don't and I usually have to add them manually using the "File System Editor" mode in the Setup Project UI. Adding shortcuts is a little hokey as well. You right click under the start menu and desktop section of the "File System Editor" mode and select create shortcut. This is all by memory so hopefully I'm getting this right. You will certainly have to test your installer multiple times before you get it just how you want. I like to test under a VM as well.
Finally, the VS Setup project produces a setup.exe and .msi file. Setup.exe is used for detecting and installing dependencies (such as .Net) before unpacking the actual DLL.
When u do this File > New > Project > Setup and deployment >
then right click Application folder> Add > File...and add your app's .exe file and also you can add shortcuts of your app in desktop and program's menu
I would recommend you to go for some tool for creating msi.
I am using WIX
What you need depends on... what you need.
For a large percentage of applications, all you need the installer to do is let the user choose an install location, copy files to a directory structure at that location, and create a few shortcuts. For that, a Visual Studio Installer -> Setup Project is fine. It can handle this basic functionality, as well as installing prerequisites like the .Net Framework redistributables, providing custom install options, and/or writing simple registry keys. The Setup Wizard creates a Setup Project as well, but runs you through a wizard to set up the basics. This is a good option if you've never created an installer before.
If you want this application to be controlled by a larger, more custom install, choose the CAB Project; it will simply pack the necessary files into an archive that is easily accessible from another setup project.
If you are publishing a class library, use a Merge Module. Merge Modules work within install programs themselves, providing files needed for the main application to work.
If you need serious customization, or you want to interface with existing InstallShield logic, I'd get a third-party installer. I've worked with InstallShield before, and it's pretty full-featured, but by the same token, the installers it creates are applications in their own right and can take days or weeks of logic programming to "tweak" to your satisfaction.
I have a C# project in MS Visual Studio 2008 that I would like to share on Google Code...I am not sure exactly which files I should be sharing on Google Code if I want to involve other contributors? What I am exactly unsure about is whether to share the entire solution folder or just the .cs files? And if it's the latter how does a contributor go about building the solution and the directory structure?
Thanks
Generally I would include the project file(s) and solution file(s) as part of the source code in a team environment (such as at work), especially if they contain anything that's needed for the proper building of the code (build events, DLL references, etc.). The user file(s) and suo file(s) and stuff like that aren't needed, those are user-specific. But this is in an environment where it can be safely assumed that everybody is using Visual Studio, even the same version.
The code itself doesn't need the project/solution files to be built, and the less you can depend on them the more open-source-friendly the project really is. If the code can be properly built from the command line, or with a tool such as NAnt, then an open source project may be better off with that. So, just from a separation of concerns perspective, try to keep the dependency on the project file(s) as light or non-existent as possible.
Overall, including the project file(s) and solution file(s) is fine if your intended audience is expected to be using Visual Studio.