Activities of "cfd000"

Do not run this on a machine which has the commercial source available (which is the environment your customers must use). When you use a machine which is configured the same way as your customers, you will see the following:

C:\Temp\ABPTest\Volo.Abp.TextTemplateManagement\host\Volo.Abp.TextTemplateManagement.Web.Unified\Volo.Abp.TextTemplateManagement.Web.Unified.csproj :
 error NU1106: Unable to satisfy conflicting requests for 'Volo.Abp.Core':
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.Castle.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Sms 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Sms 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.BlobStoring 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Commercial.Core 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.Security 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.Http.Abstractions 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.Security 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.Guids 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.Specifications 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.AspNetCore.Abstractions 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Gdpr.Abstractions 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.AspNetCore.Abstractions 8.3.1)
 Volo.Abp.Core (>= 8.3.1) (via package/Volo.Abp.Gdpr.Abstractions 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.VirtualFileSystem 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.ObjectMapping 8.3.1)
 externalProject/Volo.Abp.Core (>= 8.3.1) (via project/Volo.Abp.AspNetCore.Abstractions 8.3.1)

This goes on for nearly 500 lines. It happens everywhere a commercial package is referenced that we cannot get source to.

1. I specifically requested a CLI method. I need to script this so that it is done exactly the same way each time we do a major upgrade, and so that each step is done in order and documented. This script is part of our source code.
2. The 'new' CLI is broken. Run "abp list-modules" and tell me how to parse that output to know which modules to request source code for, and which are included in the open source framework.

# Run the abp list-modules command and capture the output
$moduleList = & abp list-modules

# Parse the module names from the command output
$moduleNames = $moduleList | ForEach-Object {
    if ($_ -match '^>\s(.+)') {
        $matches[1]
    }
}

# Iterate over each module name and run the abp get-source command
foreach ($module in $moduleNames) {
    Write-Output "Getting source for module: $module"
    & abp get-source $module --output-folder $module
}

3. How do I know which modules are pre-installed in the new project created by the CLI, and which need to be added by running "ABP add-module"?

Please provide specifics. What are the CLI command that should be used?

1. When I run the CLI command to get a list of modules, how do I tell which are PRO modules, and which are already part of the open source ? Under the 'old' CLI, they were separated, but under the new CLI they are not.
2. What location do I use for the source of the PRO modules? Do I put them in a folder at the same level as the framework?
3. When using the new CLI, how do I know what name to use for the download? Many of the modules cannot be downloaded without changing the name (such as removing '.ABP' from the name).

• ABP Framework version: v8.3.1
• UI Type: Blazor WASM
• Database System: EF Core (PostgreSQL)
• Tiered (for MVC): yes

What is the recommended way to create a new solution and incorporate all ABP source code using the CLI? This should include the base framework as well as any module source required (both open source and PRO modules).

We have a license for ABP Commercial with includes full source code. Any time we have needed to make a temporary modification or fix to the source (could be a breaking change, an immediate need to reference an updated NuGet package with a security update, etc.), it is too time consuming and error prone to switch from packages to source, so we must build our production release from full source to begin with. We would like to use the CLI so that we can script it and reuse the code for each major release (create a new clean ABP solution, validate that it builds, then bring over our changes from the prior version).

powershell -Command "Invoke-WebRequest -Uri https://github.com/abpframework/abp/archive/refs/tags/8.3.1.zip -OutFile C:\Temp\AbpTest\abp-8.3.1.zip"
powershell -Command "Expand-Archive -Path 'C:\Temp\ABPTest\abp-8.3.1.zip' -DestinationPath 'C:\Temp\ABPTest'"
cd /d C:\Temp\ABPTest
ren abp-8.3.1 abp
abp get-source Volo.Abp.TextTemplateManagement --version 8.3.1 --output-folder Volo.Abp.TextTemplateManagement
dotnet build .\Volo.Abp.TextTemplateManagement\Volo.Abp.TextTemplateManagement.sln
@REM Successful
abp.exe switch-to-local --solution C:\Temp\ABPTest\Volo.Abp.TextTemplateManagement\Volo.Abp.TextTemplateManagement.sln --paths C:\Temp\ABPTest
dotnet clean .\Volo.Abp.TextTemplateManagement\Volo.Abp.TextTemplateManagement.sln
dotnet build .\Volo.Abp.TextTemplateManagement\Volo.Abp.TextTemplateManagement.sln

That's an incredibly frustrating answer - what's wrong with the information I already provided? Do you need me to explain how to run your CLI? How to use it to create a solution? How to download module source?

• ABP Framework version: v8.3.1
• UI Type: Blazor WASM
• Database System: EF Core (PostgreSQL)
• Tiered (for MVC): yes
• Exception message and full stack trace: "Unable to satisfy conflicting requests for 'Volo."
• Steps to reproduce the issue: Create a new solution using CLI referencing packages - it will compile. Switch to local source, and now the same project throws many compile errors about conflicting requests. The same thing happens when downloading source for modules. They compile until the CLI option to use local source is run.

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:

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.

Suite needs to find Volo.Abp.Commercial.SuiteTemplates.dll in your project output directories. As I understand you exclude this DLL. Suite will not work if it cannot find this file because all the templates to generate the code are in this file.

Please read the posted question before responding - this response makes no sense in response to the problem reported. We are not using SUITE, we are using CLI. We are not excluding anything - we are creating a new solution, and it contains references to the projects under the 'licensing' folder, which are not part of the source that is released - hence the solution fails to compile. Once I MANUALLY go through all project files and replace project references with packages references I can make it compile, but it is broken "out of the box".