I know that I can pre-install NuGet packages in my project templates.
But I wasn't able to find out whether it is possible to load these packages online instead of having to store them somewhere in the project template.
If this is possible please give me a hint where I can find an example.
Older article, but answers the question:
http://blogs.msdn.com/b/marcinon/archive/2011/07/08/project-templates-and-preinstalled-nuget-packages.aspx
A frequent question is why not support downloading the nupkg files directly from http://nuget.org. We decided not to support such an option because users expect project templates to instantiate quickly and downloading files from the internet would slow things down. Also, it would not work on a plane or in other situations where a connection is not available.
Related
I have a mobile app app_Old and app_New I have restructured the old into the new, now I want all the packages installed in the app_Old to be installed on app_New. I don't want to manually install it by copying the name and installing nuggets package one after the other. How can I achieve this?
First, I am going to question the wisdom of this proposal. Generally speaking, blindly reinstalling all packages in a new project seems like a great way to replicate / create bloat for libraries you may not be using. NuGet Packages should be installed on an AS NEEDED basis especially for a mobile solution where perhaps space is more restrictive. Often you will be adding libraries which are deployed with your project and cause unnecessary bloat if these are not used. The fact that you have "over 50" on your old project, makes me wonder if there are unneeded packages.
However, there are are a few ways you can do this faster. You could edit your project files manually adding / copying and pasting references and then restoring the packages. The other way is to make a script you can run against the project. You may be able to more quickly do this than point and click re-installing and waiting. Start here for the NuGet Command Line Reference (CLI): https://learn.microsoft.com/en-us/nuget/tools/nuget-exe-cli-reference
Furthermore, keep in mind that just because you have "over 50" nugets installed, doesn't mean you have to install 50. Many of these may get automatically installed as dependencies of other packages.
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
The following problem does not exist in VS2013 (Premium),I can only reproduce it in VS2015 (Enterprise)
I've added a custom NuGet package source.
If that source if not available I cannot install any package (for example EntityFramework)
I get a message
Attempting to gather dependency information for package
'EntityFramework.6.1.3' with respect to project 'ConsoleApplication9',
targeting '.NETFramework,Version=v4.5.2'
Exception'System.AggregateException' thrown when trying to add source
'http://XXX/FeedService.svc/'.
Please verify all your online package sources are available.
From the last line of the message I assume that this is not a bug but as I said it works on VS2013
Any idea why this has changed?
Can I do anything about this?
This is by design. Since we support searching across multiple sources for the packages that you need, we need to be able to reach all sources and get the package results before restoring these packages, to be deterministic and consistent in the way we do restore.
However, we understand that some users go into offline/online modes and we are investing in building a feature set that will enable you to temporarily disable some sources while you are working offline. In the meantime you can look into creating a custom nuget.config that does not contain the offending source and using that to restore when you are in the offline mode.
This is an old question so I'm surprised the workaround from the bug report wasn't added here. To save reader a click:
From within Visual Studio, open Tools -> Options -> NuGet Package
Manager -> Package Sources
Untick all of the package sources that are unavailable, leaving just
the public NuGet entries.
Install your packages as normal
Once you're back in your office follow steps 1 and 2 again but this time make sure everything is checked.
I recently noticed that a installer file named lockbackreg.msi is included in a setup package that I use to install a large application on my machine. This file is said to be a MS .NET Update required by Office 2003 for addin functionality but I could not figure out the exact use of it.
Does anyone has any information on why this file is required?
That's part of the KB908002 update package which also distributes extensibility.dll ( .msi ) and a couple other components.
http://support.microsoft.com/kb/908002
I don't know all of the details, but I do know this is a dependency of several assets in my software product line where I work. These assets have to do with certain plugins / interop capabilities that we created for Excel, Powerpoint and Word for "pasting" to them and they won't work with out it. This is a really large install that I create so I almost can't help wonder if you are using one of my installs.
I'd also look at all the "related" questions on SO. The systems seems to be smart enough to answer the question for you.
We're making the switch from SourceGear Vault to TortoiseSVN with VisualSVN for Visual Studio integration - absolutely love it. However, there are multiple class libraries that we reference in multiple different applications that aren't a part of the working copy root in any of the applications. What's the best way to deal with this so that we can continue to utilize Visual Studio integration, but still keep various class libraries located outside of each project/application's root? SourceGear doesn't have an issue with this.
It is possible to add class libraries separately just using TortoiseSVN in explorer, but there's no ability to commit changes to anything outside of the working copy from within Visual Studio; neither are there the VisualSVN "traffic lights" indicating status for these outside of working copy class libraries.
By the way, we're also going with the "one repository with many projects" route as opposed to multiple repositories, especially as that is how we have worked for years to this point.
UPDATE:
I re-read some things that I had looked at before and discovered that svn:externals don't just refer to using code in different repositories, but can also be used to use multiple working copies in VisualSVN.
See http://www.visualsvn.com/support/topic/00007/ and http://svnbook.red-bean.com/en/1.2/svn.advanced.externals.html
However, is this the best way to deal with this issue? There's a good thread that goes through things, but doesn't completely resolve things.
Therefore, use svn:externals or not? Use multiple repositories or not? Again, for years we have referenced the code in shared class libraries amongst multiple solutions/applications and this works for us. Now how best to make this work with VisualSVN?
Found the best answers here:
Referenced Projects
Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different subdirectories to come from different locations in a repository, or perhaps from different repositories altogether. If you want every user to have the same layout, you can define the svn:externals properties.
And here:
Include a common sub-project
Sometimes you will want to include another project within your working copy, perhaps some library code. You don't want to make a duplicate of this code in your repository because then you would lose connection with the original (and maintained) code. Or maybe you have several projects which share core code. There are at least 3 ways of dealing with this.
I understand it's been more than ten years since you asked this question, but I am glad to tell you that there was progress in implementing support for multiple working copies in the VisualSVN plug-in.
VisualSVN 7.1 and 6.5 support multiple working copies within a single solution. The new functionality is available to Visual Studio 2019 and 2017 users.
Download the latest VisualSVN builds from the main download page. Please also see the article KB7: Using Multiple Working Copies in VisualSVN.