For packages which aren't restored by NuGet (normally because the package is specific and unique to projects you work on), where do you put the package files?
NuGet convention is to have a folder named packages in the root of the solution.
There's a question which already references this issue: managing non-nuget dlls along with nuget packages
And I agree that having a separate folder of non-nuget packages which are source controlled is a good idea.
But what should the name of the folder be? Is there a convention here? A process recommended by Microsoft?
The only name I've seen is NonNugetAssemblies.
Related
I am trying to use the Open-XML-Powertools.
I have downloaded the current version from GitHub and I am copying a lot of code from the sample file
Open-Xml-PowerTools-vNext\OpenXmlPowerTools\WmlToHtmlConverter.cs
However, in application I am actually using the nuget package OpenXmlPowerTools Version 4.5.3.2, which is marked as the latest stable version.
Part of this code uses the method MetricsGetter.GetTextWidth:
var w = MetricsGetter.GetTextWidth(ff, fs, sz, runText);
However, this method is not present in the version of MetricsGetter in the nuget package.
Short term I can copy the source code of this function into my application, so will not be a big problem, but which version is up to date?
Is the code in GitHub newer than the code in the nuget package?
Or older?
Is there an alternative method which I should use with the nuget package?
Unfortunately, the NuGet package is very much outdated. Thus, the best approach is to:
fork (optionally) and clone EricWhiteDev's Open-Xml-PowerTools repository,
build the OpenXmlPowerTools.dll assembly from source,
put that assembly into a libs folder (or whatever you use), and
reference that assembly in your projects.
The previously official OfficeDev/Open-Xml-PowerTools repository has been archived.
I have pulled an in-house NuGet package's source into a new class library project of my solution, removed all references to the original package and referenced the class library. The solution builds just fine but when I run it I get the classic...
Could not load file or assembly 'Standards.Environment, Version=12.8.0.0, Culture=neutral, PublicKeyToken=e1f2345a678912bc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
I've searched SO and tried the solution here: How to resolve “Could not load file or assembly... to no avail.
What I don't understand is that I get the above error even though the AssemblyInfo.cs of the Standards.Environment class project contains these lines:
[assembly: AssemblyFileVersion("12.8.0.0")]
[assembly: AssemblyVersion("12.8.0.0")]
Have I forgotten to do something when migrating the source code into my solution?
EDIT I have discovered that one of the other in-house NuGet packages is referencing the same package which I have removed (because I migrated its source into the solution.)
How can I force the other NuGet's DLL to accept the DLL of the class library as the dependency it is looking for?
The cause of the problem was that I had removed a NuGet package which contained the DLL which another NuGet package was looking for. When I migrated the original NuGet source into my solution it broke the references.
The solution was to switch back to using both NuGet packages and let them sit happily alongside each other OR import both.
Not particularly happy with this, but reverting back to a previous version of the solution and solving the real problem (an unrelated bug) was easier once I understood this.
We (me and three other people) will make an ASP.NET MVC application and use GitHub for version control. We've added some NuGet packages like Unity.MVC5.
Person one has commit and sync the project to the master branch. He's got no problems. The other three people sync the branch but they got problems with the NuGet libaries. See errors below:
Error: This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props.
Error: Metadata file D:\...\MarkeOnlineWebsite\MarkeOnline.Website\bin\MarkeOnline.Website.dll could not be found
Warning: The referenced component ... could not be found.
Update: I've also added this .gitignore file.
How could we solve this problem?
I downloaded a Meteor Starter project called MeteorAdmin.
In the root of its directory tree, you find a packages directory that contains few packages (boostrap, comments, few others) and also, in the .meteor directory there's a file called packages that defines the dependencies of this project.
What is the difference between them? What I found interesting is that .meteor/packages contains bootstrap as well. In theory shouldn't that be enough so that bootstrap would get downloaded to the project?
The meteor packages file simply lists all of the apps dependencies as well as the load order of each (top to bottom). You can edit this file if you know what you are doing, but it's probably better to leave it alone until you are more familiar with Meteor.
The way you add packages is by typing meteor add <package-name> in your terminal and then it will be added to your project. Additionally, the name of the package will be added to the bottom of your packages file.
A meteor app can have local packages that are defined in the packages folder of the root directory. This project likely is implementing it's own bootstrap package and then added it with the meteor command I listed above. Once a local package is added to your project with the meteor add command it's package name will appear in the packages file just like packages from Atmosphere. I hope that answers your question... Let me know if you were looking for something more specific.
I installed couple of packages for 'Project A' (e.g bootstrap) assuming that it will be available for all subsequent projects. But when a new meteor project 'Project B' was created, meteor list showed only default packages. So my assumption that meteor packages are like ruby gems available globally is incorrect. As I work offline every now and then, Is there a way I can manually copy/re-use installed packages?
Yes they are similar to gems. Packages are installed in ~/.meteor/packages, in precompiled form. They can be installed globally this way.
When you add a package to your project it will essentially copy the package from there into your build-cache directory hidden in the .meteor directory of your project.
To install a package locally where you can easily re-use it you would have to clone the github repository of the package and place the output in the /packages directory of your Meteor app.
For example for bootstrap, twbs:bootstrap you would clone this reposistory: https://github.com/twbs/bootstrap, into a directory like /packages/twbs:bootstrap (name doesn't matter if its defined in the package.js file on the repository.
In general you can easily re-use a package without the hassle of adding it in manually like so. It's better to use the global packages which are kept up to date.
The trouble comes with being offline. If you use a local package its nearly guaranteed to always work. Whereas the global ones can give a bit of trouble once in a while when you try to add a package in as meteor tries to check the package is up to date, especially where npm packages are involved with the package.
To keep it short if you added a package in using meteor add twbs:bootstrap you should most likely be able to add it to another project using the same command. Only if you keep your packages & meteor up to date.