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.
Related
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.
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.
ASP.NET 4.5.1 or 4.5.2
Updating Nuget package MicrosoftAspNet.Identity.EntityFramework from version 2.2.1 to version 3.0.0-rc1-final
I get the following error:
Failed to add reference. The package 'Microsoft.AspNet.Identity.EntityFramework' tried to add a framework reference to 'System.Runtime' which was not found in the GAC. This is possibly a bug in the package. Please contact the package
owners for assistance.
I had a similar issue with another package.
I "solved" it adding a manually reference to missed library, updating the package and then removing the reference added manually:
On your project go to References -> Add Reference... and then click on Browse...
On my installation (Windows 10), your file is located on: C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Runtime\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.dll
Add, update and then remove.
I know, it is not a solution, but it will allow you continue working until get a real solution.
I had the same issue, but adding the MySQL package to my project.
The way that i solved was just very closely to the answer given by Sebastián Guerrero.
So i will be adding a manually reference to that missed library (system.runtime) and than installed the MySQL package and it works perfectly.
ATTENTION: I only unnistall the system.runtime package after installing the MySQL.
References -> Add Reference... and then click on Browse...
On my installation (Windows 10), your file is located on:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Runtime\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.dll
I had the same issue when running Install-Package Microsoft.Azure.Management.Fluent on .NET framework 4.5.2
Solved the issue with the following steps:
Installed Microsoft.Rest.ClientRuntime latest version from Nuget.
After that, installed latest version of Microsoft.Azure.Management.Fluent from Nuget.
I had this problem when I opened the project after a while.
The problem was it was originally built with Microsoft.Net.Compilers.2.4.0 and I was on 3.3.1.
The project strangely added two required Imports to the .csproj file, one for the 2.4.0 compiler,and a duplicate for the 3.3.1 version. I just needed to:
Right click on the project file
Unload the project
Edit the csproj file
Remove the 2.4.0 references (was also a reference in an Error element)
Close file
Right click on project, reload file.
Rebuild All
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 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.