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
Related
I work at a company where we have a monolithic application and I want to split it out into smaller web services / windows services / websites e.t.c
I want to be 'smart' and re-use libraires contained in the monolith by putting them into their own class libraries and creating a NUGET package for them on build, using Azure Devops (although not entirely bound to this tool).
The main one I am attempting to isolate is the Data-Access Layer, as it is the most commonly used.
So far, the CI side will build one of my class libraries, and publish an incremented version number to a nuget feed I can connect to through VS.
The problem is, I cannot for the life of me figure out how to debug these nuget packages as if we were still debugging in the monolith - and we are all very used to being able to debug through the entire end-to-end of request -> response.
I think I essentially want to
Host a nuget package
Have it able to be built in DEBUG or RELEASE variants, (release on publish, debug during development)
Step into the library easily, with full source and variable watch abilities, as if we were still in the monolith design
I refuse to believe this isn't possible as I assume most companies who craft good code will surely do this, or am I thinking about it all wrong?
The only thing I've managed to find online is someone who actively copies nuget packages locally to his machine, builds them in debug and drags pdb files across - which would be more hassle than its worth and make me want to just 'stick to the monolith design'.
It depends on your expectations, or what you consider the definition of debugging. Say you're debugging and the bug is indeed in the package. Do you expect to be able to change a few lines of code of an assembly in the package, build a new version of your app using the dependency and run again? In that case no, it's not going to be as easy as that and you're best off keeping everything in a single solution, even if they're deployed as multiple services.
However, if you just mean using Visual Studio's debugger and being able to step into methods, then you can use the Azure DevOps Pipelines task to publish symbols. Note this is different to using a symbols package or snupkg like if you were publishing symbols to nuget.org. The Azure DevOps task is just copying the *.pdb directly to their symbol server. Each developer will also need to configure their VS one time to use the symbol server.
I'm building a web app project and want to reference a few dlls from a desktop c# project. Both projects are pretty big.
This has all grown organically, so what we've done so far is include the dll projects in the web app solution which makes it easy for debugging. So at the moment all our code (desktop apps and web apps) sit in one big git repo and we build the web app and copy the code to a web server via Jenkins.
The time has come to manage the code better and split the repo into two. The problem I'm having is that I can't build the code anymore as is via Jenkins as the desktop app code (and dlls) will be gone from the Jenkins working directory (unless I create a common working directory).
I just want to get some ideas how to best manage the code:
- How do I best include the desktop c# dlls in my web app solution?
- Is there any way to still being able to debug the dlls if I don't include the dll projects in the web app (when debugging the web app)?
- How do I keep the dlls in the web app solution up to date (say if I put them into the bin folder)?
- Is there a way to not include the dlls in the repo, but have Jenkins rebuild and copy the dlls?
You can host your shared DLLs in a nuget package in its binary format and have it referenced by both the desktop and the web application.
I don't know about the Jenkins part, but a quick google said that there is a plugin that support nuget.
Creating nuget packages is an easy and straight forward process with adding some meta data about the nuget in a nuspec file and calling nuget.exe with some parameters to create the package (nupkg) for you, that you can later reference in your project.
Hosting nuget packages to be found and used later, you will need to create a feed. it can be as simple as storing files in a folder somewhere and configuring your build tools (visual studio, MSBUILD, etc.) where to look to find nuget feeds.
referencing a nuget is done in visual studio via nuget package manager plugin.
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 :)
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.
We found a bug in Web Service Software Factory a description can be found here. There has been no updates on it so we decided to download the code and fix it ourself. Very simple bug and we patched it with maybe 3 lines of code. However* we have now tried to repackage it and use it and are finding that this is seemingly an impossible process.
Can someone please explain to me the process of PLKs? I have read all about them but still don't understand what is really required to distribute a VS package.
I was able to get it to load and run using a PLK obtained from here, but i am assuming that you have to be a partner to get a functional PLK that will be recognized on other peoples systems?
Every time i try and install this on a different computer I get a "Package Load Failure". Is the reason I am getting errors because I am not using a partner key? Is there any other way around this? For instance is there any way we can have an "internal" VS package that we can distribute?
Edit
Files I had to change to get it to work.
First run devenv PostInstall.proj
Generate your plks and replace ##Package PLK## (.resx files)
--Just note that package version is not the class name but is "Web Service Software Factory: Modeling Edition"
-- And you need to remove the new lines from the key
ProductDefinitionRegistryFragment.wxi line 1252(update version to whatever version you used in plk)
Uncomment all // [VSShell::ProvideLoadKey("Standard", Constant in .tt files.
The short answer is no, you don't need to be a VSIP partner registered with Microsoft to obtain and use a PLK. The PLK you obtained from the site should work on any VS install. (On a related note, Microsoft has eliminated the requirement for PLK's altogether for VS 2010.)
The following pages should help with debugging what the issue is:
http://msdn.microsoft.com/en-us/library/bb164677.aspx
http://blogs.msdn.com/dr._ex/archive/2006/12/14/debugging-package-load-failures.aspx
There is also a tool in the Visual Studio 2008 SDK called the Package Load Analyzer that should help you debug the load failure (and confirm that it's actually a PLK issue and not something else). Copy and run VSSDK_PLA.exe (under VisualStudioIntegration\Tools\Bin under the VS SDK install location) to your test machine to install the Package Load Analyzer tool.
You don't have to worry about package load keys when rebuilding the Web Service Software Factory because it is a guidance package that depends on GAX, which has the only PLK needed. To build guidance packages, like the Service Factory, you also need to have GAT installed.
The Service Factory source should contain the setup projects you need to build and redeploy it. If you have an issue, the discussion forums on its community site (http://servicefactory.codeplex.com) are monitored by team members. Response is pretty good.
Aaron is right that this whole story gets a LOT easier in VS2010. VSIX is pretty sweet. We are updating the Service Factory to VS2010. It should be ready for release within a month.
Don
MS p&p