I have created an VS Addin that creates a new project conform my specs and file structure.
It does all the heavy lifting as cloning repos from mercurial, adds the needed references to assemblies and projects in the solution.
Now I want to bring it one step beyond.
Is there a way to invoke Nuget from my add-in.
If so then I can install my "standard" packages right after the new solution is created without my personal intervention.
In Nuget there is a reference TO the DTE, but is there a way to use it FROM the DTE.
Use NuGet.CommandLine. You can read how to use it here.
Also make note that NuGet 1.5 brings some new features, though I'm not sure how relevant they are for you.
Related
I have set up a TeamCity partly. Now it downloads the code from TFS and try to build it using MSBuild which was not successful. I know that I am doing something wrong. I have some library added to my code(An ASP.NET website). I know that it is not a good idea to add dll files to Version Control(TFS), but if I don't check them in, when TeamCity downloads the code, it does not have that libraries so MSBuild cannot successfully build it. I was wondering what would be the best practice to solve that issue?
For dependency management in .net I would recommend that you take a look at the TeamCity built in nuget feeds. You have a possibility to utilize a feed directly from within TeamCity, acting as a server. As you state, commiting dependencies in (any) VCS should really be avoided...
It depends on what type of dlls you're dealing with.
If they are available on NuGet.org, use NuGet and the Package Manager Console to add the references to your solution. Then just put NuGet.exe on your Build Server, and run
NuGet.exe restore YourSolution.sln
As your first build step.
If they are in-house dlls, then you have a few options. The first being, as TeNGiL mentioned, setting up a private NuGet repository, and publishing the in-house dlls, to that feed, and pulling from it within your build server.
The other option is just to create a 'References' directory in source control, which holds dlls, reference them in your solution from the source controlled directory, and then pull them down as part of your Build Configuration. This really isn't as bad as it sounds, within reason, and is a perfectly acceptable interim solution to incorporate until everyone is on board with using a private NuGet feed, or something of that nature.
Open the code in the checkoutdirectory of TeamCIty in visual studio and try and build.I am pretty sure that visual studio will give you the exact error message of what's going wrong.
Missing packages have to be restores. Use a Nuget Installer build step to restore your packages as given in image below.
I am hoping for a little advice.
I am checking in my project (asp.net mvc 5) to source control (TFS) and when a fellow colleague tries to pull it down, most of the references are not being added to his project.
How can I insure that all the references to get added?
Generally, best practice is to use NuGet.
At least for packages that are not internal you must use NuGet. Let's say for EF, BundleTransformer & so on.
For that you must enable NuGet package restore and fetch all you need from NuGet Feed. More here: http://docs.nuget.org/consume/package-restore/msbuild-integrated
For internal dll's you can create an internal NuGet feed: https://docs.nuget.org/create/hosting-your-own-nuget-feeds and get packages from there or copy them in your project.
Don't forget to include the files into project if you copy them "by hand" and i think this is a good start.
There are other best practices like not referencing anything from GAC anymore and move all the dll's/dependencies/referencing to NuGet or to create a raw "Library/Vendor" folder in your project and copy all the necessary DLLs there (problem here is that you check in all the dll's to source control), but you will be sure that everyone will get exact the same version/reference & so on because the files are stored there (physically).
What are the references to?
There are a few different things to bear in mind:
References to other projects within the solution should just work, if they don't make sure that the referred to projects are building
References to things like nunit are best managed through nuget so you add them using it and then when your colleague checks out he only has to restore the nuget packages and it all works
References to things that aren't in nuget, you can either put them into nuget or I prefer to create a lib folder and put them into there. To get them actually checked in as dll's are normally excluded, add the folder and dll's and then use the source control explorer to find the folder, right click and choose "Add items to folder" and use that to add the dll's and files that you need. If you then reference the dll's in the lib folder they will be checked out and should resolve correctly for the other user.
At my work we are just starting to use TFS with our team of 4 developers, and are at the same time transitioning from single developer projects to team projects. We are mostly using the default settings in TFS
I was the first to push up a simple Silverlight MVVM project consisting of a solution with a Silverlight and a web project.
When my team-mate pulled down my code and tried to compile, he was faced with many missing references (.dlls), Expression blend SDK, Ria Services toolkit, Telerik controls, simple mvvm toolkit, silverlight toolkit, etc.
What do we need to do, to add projects to TFS that have everything needed to be compile it when the next developer pulls it down?
There isn't a really good way to do this all automatically. What you'd generally do this this:
in your branch create a bin folder next to your src folder.
in the bin folder create folders for each component you're relying on
in each folder place the setup or a link to the setup
in each folder place the binary files you're using in your solution
in each folder place a readme with any manual steps that must be completed
if wanted you can create a powershell script or batch file which installs all required components. It isn't too hard to detect whether or not an application is already installed using powershell and wmi
Now you'll have to fix a few things in your solution:
make sure your references don't point to the GAC, but that they point to the assemblies inside the bin folder of your branch
make sure all the paths are relative to the solution. Any c:... paths will not carry over from one system to another
I found that the easiest way to do this is to unload the project in Visual Studio and then edit it. You can then quickly add hintpath="..\..\..\bin\component attributes to each reference. There are a few blog on this subject which provide different solutions which all solve this same issue.
This setup allows you to at least get the latest version of any solution and build it without having to install any tools. If some of your components rely on visual studio add-ins, then the designers for these tools usually won't work, but at least you're able to build them.
An often used alternative is to create a Virtual Machine base image for your project and install all the required components onto it. Then copy the image to each developers workstation and sysprep it to ensure they all have a unique name and identifiers. When the project needs to update its dependencies, let one developer create a new clean machine and re-distribute that to all team members.
If you're using Windows Server Virtualization or VMWare, it's quite easy to create differencing disks and allow developers to access these images remotely.
Another approach would be to use NuGet and script NuGet using a powershell script for your solution. This will work for most cases, but products like Expression Blend still need to be installed separately.
Our projects in TFS are organized like this:
$\DefaultCollection\ProjectName\Source <-- source code goes here
$\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here
Now that NuGet is on the scene, is there any reason to change our approach and use NuGet's packages folder for dlls that come from NuGet-aware projects? I'm leaning against this because
1) it creates two places one must look for dependencies
2) it leaves us open to one developer updating a package and breaking some dependency
That said, if anyone can report a good reason to start using NuGet in a TFS environment, I will happily present your ideas to my team as if they were my own (joke).
Nuget 1.6 now allows for packages not present to be downloaded dynamically upon build. So you can now check in to source control without the .dlls, but the build itself will pull the correct package.
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
I'm a Fossil (and CVS configuration) novice attempting to create and manage a set of distributed Fossil repositories for a Delphi project.
I have the following directory tree on my development machine:
Projects
Some Project
Delphi Components
LookupListView
Some Client
Some Project For Client
Some Other Project For Client
Source Code
Project Resources
Project Database
I am setting up Fossil version control in order to version and share Projects\Some Client\Some Other Project For Client\Source Code, which contains Delphi 2010 source for a database project.
This project makes use of Projects\Delphi Components\LookupListView which is a Delphi component. I need this code to be included in the versioning system for my project. I will, in theory, need to include it in other Fossil repositories in the future, as well.
If I create my Fossil repository at the Source Code or Some Other Project For Client level, I cannot add any code above that level to my repository. What is the proper way to deal with this? The two solutions that occur to me are
1) Creating a separate repository for LookupListView and make sure that everyone who uses a repository for a project that references it "knows" that they must also get the current version of this project as well. This seems to defeat the purpose of being able to obtain a complete, current version of the project with a single checkout. The problem is magnified because there are other common component dependencies in this project.
2) Establishing my Fossil repository in the Projects directory, so I can check in files from various subfolders. This seems to me to involve an awful lot of extra path-typing when doing adds, and also to impose my directory structure (Some Client\Some Other Project For Client\Source) on the other users of the repository -- in this case, the actual client.
Any suggestions appreciated.
I use Git, but my approach can be applied in your situation.
I have one repository for all my components folder. This gives me an ability to get all of them with only few console commands (in case when I reinstall my OS or go to another computer etc.).
Also I have one repository per each of my projects. If some project uses 3rd party controls I create "components" sub-folder and do symbolic links (junctions) of every components set.
This approach have some disadvantages (when you "go back" in commits history of some project, components can be modified too. And if many projects are using same components this could cause some troubles). But I had no issues yet :)