file src attribute being overwritten

[markjerz]

Hi! Thanks for reporting this feature/bug/question!

Please keep / fill in the relevant info from this template so that we can help you as best as possible.

Type (choose one):

• Bug

NPE version: 4.1.32+gafe915819a

Installed from: Windows Store

In case of a BUG:

• What is the current result?

When using "Save Metadata As" it's overwriting the src attribute on files to match the target instead of leaving it as is. See the attached git diff:

• What is the expected result?

It shouldn't be overwriting the src attribute.

• Please post full exception details in case of an Exception (message, stacktrace, inner exceptions).
• Are there any workarounds? yes/no
• Is there a version in which it did work?

Yes, definitely the 3.x series, so feels like a recent regression.

[304NotModified]

yes, unfortunately the nuspec will be fully generated from the specs

This is also an issue if there is a wildcard in the src=

[Bhaal22]

Hi,

I get this issue also while upgrading to 4.1.38. 3.25 is working fine

[Bhaal22]

Issue is related to this Extension when ExportingManifest. The cast is not possible and returns always null.

Will make a small PR for review. Not sure about the fix.

using NuGet.Packaging;

namespace NuGetPe
{
    public static class PackageFileExtensions
    {
        public static string OriginalPath(this IPackageFile packageFile)
        {
            return (packageFile as PhysicalPackageFile)?.SourcePath;
        }
    }
}

[clairernovotny]

@Bhaal22 not sure what you mean by the cast not being possible?

[Bhaal22]

@onovotny Just did a dummy PR

https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/pull/373

in the call

manifest.Files.AddRange(RootFolder.GetFiles().Select(
                        f => new ManifestFile
                        {
                            Source = string.IsNullOrEmpty(f.OriginalPath()) || f.OriginalPath().StartsWith(tempPath, StringComparison.OrdinalIgnoreCase) ? f.Path : PathUtility.RelativePathTo(rootPath, f.OriginalPath()),
                            Target = f.Path
                        })
                    );

The cast done in "packageFile as PhysicalPackageFile" is ALWAYS null then OriginalPath is ALWAYS null, then we always set f.Path for ManifestFile::Source

[Bhaal22]

I definitely do not say f type is ManifestFile

From what I have debugged,

GetFiles() call returns List<IPackageFile> whose each element is of type PackageFile and a PackageFile is not convertible to a PhysicalPackageFile. They both implements IPackageFile

only PackageFile::_file is of type PhysicalPackageFile

the PR I refer is definitely not complete I agree.

[c0pp3rt0p]

This still appears to be an issue in 4.4.3. Is there a workaround or any progress on the PR? The diff above provided by markjerz is exactly the same issue I'm seeing.

[clairernovotny]

The PR has some issues, AFAIK. Happy to review it if someone else wants to jump in.

[Bhaal22]

Hi guyz, been busy for a while. Indeed the PR has some issues, was just a qwuyick work around to highlight the issue and fixed it quickly.

[c0pp3rt0p]

The underlying issue is in PackageFileExtensions.cs. There is an attempt to do an 'as' conversion. from IPackageFile to PackageFileBase. The issue is that the concrete type that is behind the IPackageFile is actually a PackageFile concrete type which doesn't descend from PackageFileBase so the conversion results in null. I'm totoally new to this code, but you could just convert it to a PackageFile concrete type but then you need to add a reference to PackageViewModel to the Core project which could be undesirable. Or you could add the OriginalPath property to IPackageFile interface and eliminate the need for the 'as' conversion. If that doesn't strike your fancy create a new interface. Or the inheritance could be corrected if indeed PackageFile needs to inherit from PackageFileBase (It's ancestry is currently only PackagePart) If someone has a preference, happy to submit in a PR.

[jrt324]

This still appears to be an issue in 4.4.7

[JVimes]

Bug still in v5.2.88.