Starts in:
2 DAYS
9 HRS
56 MIN
18 SEC
Starts in:
2 D
9 H
56 M
18 S
Open Closed

Source Link floods builds with warnings #5141


User avatar
0
cfd000 created
  • ABP Framework version: v7.2.2
  • UI type: Blazor
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): yes
* **Exception message and stack trace**: C:\Users\chris\.nuget\packages\microsoft.build.tasks.git\1.1.1\build\Microsoft.Build.Tasks.Git.targets(25,5): warning : Unable to locate repository with working directory that contains directory 'D:\Blazr4722\abp\framework\src\Volo.Abp.Core'. [D:\Blazr4722\abp\framework\src\Volo.Abp.Cor
e\Volo.Abp.Core.csproj]
C:\Users\chris\.nuget\packages\microsoft.sourcelink.common\1.1.1\build\Microsoft.SourceLink.Common.targets(53,5): warning : Source control information is not available - the generated source link is empty. [D:\Blazr4722\abp\framework\src\Volo.Abp.Core\Volo.Abp.Core.csproj]
  • Steps to reproduce the issue:" Create a new solution which references local source code:
abp.exe new MyNewProject --template app-pro --ui blazor --pwa --database-provider ef --database-management-system PostgreSQL --mobile maui --separate-identity-server --separate-tenant-schema --tiered --with-public-website --no-random-port --local-framework-ref --abp-path ..\..\..\ --version 7.2.2 --output-folder D:\Blazr4722

Fix all references to 'licensing' projects, so that the solution will actually compile https://support.abp.io/QA/Questions/5140/New-Solution-Does-Not-Compile

Go to the solution directory and run dotnet build

You will receive hundred of errors related to Source Link


7 Answer(s)
  • User Avatar
    0
    jfistelmann created

    Hey,

    you can address that by removing/ commenting out the PackageReference in common.props

    You do not need the reference if you use the code directly.

    Does that solve your issue?

  • User Avatar
    0
    cfd000 created

    Thank you, that does solve the problem.

    I think this is a bug though, the publicly available source code should not be 'broken' out of the box.

  • User Avatar
    0
    jfistelmann created

    Thank you, that does solve the problem.

    I think this is a bug though, the publicly available source code should not be 'broken' out of the box.

    I understand that it bothers you. However, I don't receive any warnings in that matter. Just to clarify - when building abpframework I use this script: https://github.com/abpframework/abp/blob/dev/build/build-all.ps1

    I also would not argue that this is a bug. The abpframework is meant to be consumed by referencing the nuget packages and not by using the source directly. And when you are using the nuget packages, source linking is helpful because it enables you to debug through the code.

  • User Avatar
    0
    cfd000 created

    If we are paying for a subscription that includes source code, why would we still use the NuGet packages? The reason we are using the source is to allow us to push emergency fixes to production when ABP has not yet had time to respond.

    Here is an example - a security patch gets pushed that breaks some existing functionality (could be a .NET fix for an exploit that we are required to deploy, could be a browser patch that customers are applying themselves, etc). Our application is used for time-sensitive work and we cannot wait for ABP to implement a fix, test it, and release a new version of the framework. By building our solution from full source, we can implement our own fix or workaround immediately. We also have a fully automated and containerized CI/CD pipeline, so it isn't possible to just compile and replace a single DLL.

  • User Avatar
    0
    jfistelmann created

    The github code is free to use and targets a different use case.

    Q: Why would we still use NuGet packages? A: Because of lower build times, easier to reuse, easier to manage and versioning.

    Generally spoken, abpframework and it's modules are meant to be consumed as nuget packages.

    I understand that your use case is different from that. You have the need to change the code directly and I do not question that. As stated here https://support.abp.io/QA/Questions/5140/New-Solution-Does-Not-Compile you may want to overthink your approach on how you customize and consume the framework.

    I made this picture for clarification.

    This way, you can do whatever customizations you like - in your own source control in a manageable manner. If you do not want to use NuGet packages, you can just skip the part and use the code directly like you do it today - but from your customized repository where you've made adjustments specific to your use cases.

    Does that help you?

    Kind regards Jack

  • User Avatar
    0
    cfd000 created

    Jack, It is acceptable to simply replace the open source framework, but that doesn't begin to cover all of the complications related to updating the modules and the solution created by ABP. I made a trivial example by building a solution twice, once referencing the 3.2.0 version of ABP and another referencing 7.2.2. Once I had both created, I ran ABP UPDATE against the 3.2.0 version and compared the results. The ABP UPDATE command doesn't even come CLOSE to creating a project that is on-par with one built from 7.2.2 from scratch. I understand why this is, but the reason we pay for ABP year after year is to take advantage of all of the features and improvements that are constantly being made (which are great!). If we have to manually edit everything to update our solution then this could take days (and that's assuming that the documentation has each of these changes detailed, which it frequently does not!).

    Look at the differences in the Blazor project and Module class alone:

  • User Avatar
    0
    jfistelmann created

    Taking aside the fact that there are migration guides which did not get applied here - I now better understand what you mean. Thank you for that example.

    The cli - at least at the moment - only updates package references. Therefore, everything else needs to be done manually as described in the migration guides. Can you point out a specific case where the migration guides did not include such a change? I would then discuss it internally.

    Apart from that, I see that we have multiple points here. If I get you right, you wouldn't use the update command even if it did produce the same outcome (update and new) - as you have your own code in place.

    How would you describe a desirable outcome for this issue/ what would need to change?

Made with ❤️ on ABP v9.1.0-preview. Updated on November 20, 2024, 13:06