-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we downgrade DocumentFormat.OpenXML to 2.20.0 #14941
Comments
@hyzx86 Enhance your code to use the latest. Don't could on OC to maintain a version that your project is stuck with. Also, you may be interested in content transfer module which has powerful import/export content items from/excel. It's currently using EPPlus library, but the plan is to remove EPPlus and replace it with another library. |
@MikeAlhayek Yes , I noticed the PR, but there were some licensing issues with EPPlus, so I used ClosedXML, but the DocumentFormat.OpenXML it relies on hasn't been updated yet, Due to some disruptive updates introduced by OpenXML 3.0 to optimize.net8, it is currently cumbersome to update ClosedXML, and since the OC itself does not enforce a dependency on OpenXML 3.0, can it safely downgrade to a lower version? |
probably not. Even if we do now, there is nothing that would prevent us from update it again. On the other PR, yes EPPlus will be dropped. Feel free to contribute into that PR by replacing EPPlus with DocumentFormat.OpenXML 3.0 |
Yes, I also developed an Excel import/export feature, Will this issue be optimized in this PR? |
which one? |
Oh, haha, that's what I'm looking at. I didn't know there was another one |
Because my project structure is front-end separated and not included in the OC's module, I created a ScirptQuery that uses a Jint script to configure how to import/export the content //read excel from upload
const excelData = readExcel({
sheetName: "Trading",
startAddress: "A3"
})
// const x ={
// "SOA": "test",
// "Incoterm": "DDP",
// "Source_Country": "CH",
// "Destination_Country": "IN",
// "Total_Freight_": 5.0,
// "Total_Duty_": 5.0,
// "Other_Charges_": 5.0
// }
const contentItems = excelData.map(x => {
const content = newContentProperties({
TestTrading: {
SOA:{Text:x.SOA},
Incoterm:{Text:x.Incoterm},
SourceCountry:{Text:x.Source_Country},
DestinationCountry:{Text:x.Destination_Country},
TotalFreight:{Text:x.Total_Freight_},
TotalDuty:{Text:x.Total_Duty_},
OtherCharges:{Text:x.Other_Charges_},
}
})
return content;
})
clearContentByContentType(types.IndexTypes.TestTrading)
const total = importContentItems({
contentModelList: contentItems,
contentType: types.IndexTypes.TestTrading,
useGraphqlFormat:false,
useDefaultImport:false,
publish: true
})
return {
data: {
total
}
} |
We discussed about moving Indexing to its own module to separate it from Media, and then extending this to have a module for Pdf indexing and Word indexing too as they are adding an external dependency that we might not want to spread with each deployment. |
It looks like the feature Media.Indexing doesn't have any external dependency at all and could stay in the Media module. But each of Pdf and MicrosoftOffice indexing should be in their own module (one for each). |
Creating a module for each one will be too much, I presume the |
If a feature requires a nuget package it should introduce a module to prevent the issue that is described here. |
@sebastienros are you saying here we should add 2 new modules of for PDF and other for others? I think this would be an over kill. I create a PR that move all indexing in a separate module to but split them into multiple features. I think one module for all indexing is enough unless someone else complains about PdfPig project |
Compromise ... |
@sebastienros does that means you are okay for 1 additional project or you still prefer 2 as described in my last comment? |
One module per external dependency required would be better as suggested by @sebastienros As long as they are named something like OrchardCore.Media.Indexing.Pdf ... OrchardCore.Media.Indexing.MSDoc |
I'm also facing the same issue, but it seems they are upgrading it soon, so this might not be necessary. |
link to : ClosedXML/ClosedXML#2248 |
The dependency on DocumentFormat.OpenXML is still v3.0.0.
|
It seems that people are not ready for 3.0, because upgrading 3.0 will introduce many destructive updates. |
@MikeAlhayek is your PR fixing the issue? |
If you use latest preview 1.9, you'll notice that the only package we use OpenXML is in OrchardCore.Indexing.OpenXML. You should be able to not reference it in your project and maybe able to override the version in your own project. Can you try it out? |
Ok, I'll try, but if I want to use |
yes. |
Um, well, I've actually copy all of the media module in my project 🤣 Because the problem is hidden, it can only be discovered at actual runtime, but it has been updated several versions by the time it is discovered |
@hyzx86 could you please try it while you filed the issue, I'm currently busy with other PRs |
I don't have OrchardCore.Indexing.OpenXML referenced anywhere, and still get the original issue. (Using 1.8.1)
Unsure how could do this. But if it involves copying/overriding source code would be an ugly solution I'd like to avoid. |
I remember upgrading OpenXML was a change in the last few months, maybe you can try to downgrade to v1.7.1 of OC
If you can't downgrade OC, you can try upgrading to the preview version |
What about the current issue? |
I'm all right |
Can we downgrade
DocumentFormat.OpenXML
to 2.20.0 ?I have developed an Excel import/export function that is based on ClosedXML
Unfortunately, it relies on DocumentFormat.OpenXML v2.16.0
While DocumentFormat.OpenXML v3.0.0 was optimized for.NET 8, I tested that all OC unit tests were still available after demoting it to version 2.x
The text was updated successfully, but these errors were encountered: