Activities of "berkansasmaz"

Hi,

I will create an internal issue. This issue will be addressed in the next version.

Thanks.

Thanks for your question!

Currently, ABP Studio creates additional services with a minimal structure. You can check the detailed explanation and possible workaround here: 👉 https://abp.io/support/questions/7648/Unable-to-create-layering-for-microservices#answer-3a1447fd-ff9a-f065-3800-a436cfe3d88d

You can configure longer token lifetimes in your QA environment using the following example:

#if QA_BUILD
   PreConfigure<OpenIddictServerBuilder>(builder =>
    {
        builder.SetAuthorizationCodeLifetime(TimeSpan.FromDays(365));
        builder.SetAccessTokenLifetime(TimeSpan.FromDays(365));
        builder.SetIdentityTokenLifetime(TimeSpan.FromDays(365));
        builder.SetRefreshTokenLifetime(TimeSpan.FromYears(2));
    });    
#endif

For more details, please check the documentation here: https://abp.io/docs/latest/modules/openiddict#setting-tokens-lifetime

Hi DominaTang,

Before answering your question, I would like to ask you a question. In which environment do you run your automation tests? Do you run them on the live application or do you have a test environment where you run them?

Hi Tapmui,

You don’t need to apply authorization to Integration Services, because these endpoints are not exposed externally. If a user request is already validated by [Authorize] in your Application Service or Controller, there’s no need to check authorization again for internal calls. Integration Services are only used internally between modules or services, and users cannot directly send requests to these endpoints if it's not intentionally exposed to the outside in your deployment configuration.

See more:

• https://github.com/abpframework/abp/issues/12470
• https://abp.io/docs/latest/framework/api-development/integration-services#exposing-integration-services

Hello Yusuf,

The new solution creation process is tested by both the development team and the test team before every release. We could not reproduce the issue you reported during our tests.

The error indicates that the file is being used by another process. This often happens due to antivirus software, synchronization tools like OneDrive/Dropbox, or other services locking the file.

To identify the exact process holding the file, you can use Microsoft’s File Locksmith tool: 👉 https://learn.microsoft.com/en-us/windows/powertoys/file-locksmith

With this tool, you can see which process is locking postgresql.yml and close it before trying again.

Thank you.

Hi,

When you open the D:\Packages\volo.abp.studio.extensions.standardsolutiontemplates path in File Explorer, can you see any version folders, specifically 1.2.2?

When you open the D:\Packages\volo.abp.studio.extensions.standardsolutiontemplates path in File Explorer, can you see any version folders, specifically 1.2.2? If you can't find a folder named volo.abp.studio.extensions.standardsolutiontemplates in D:\Packages, probably you didn't set the NUGET_PACKAGES environment variable as explained here.

You can set it with the following PowerShell command.

setx /M NUGET_PACKAGES D:\Packages

If the issue still persists, the problem may be caused by the NuGet cache. You can clear it with this command:

dotnet nuget locals all --clear

Alternatively, you can manually download the extension using the command below:

nuget install Volo.Abp.Studio.Extensions.StandardSolutionTemplates -version 1.2.2 -source https://nuget.abp.io/[YOUR_API_KEY]/v3/index.json

Please replace [YOUR_API_KEY] with your actual API key, which you can find in your NuGet.config file.

Also, since your machine doesn’t have the .NET 9 SDK, please install it from the official Microsoft download page: https://dotnet.microsoft.com/en-us/download/dotnet/9.0

Hi,

It seems there is cache problem, can you try cleaning all the nuget cache and install abp suite standalone.

dotnet nuget locals all --clear

Install/update abp cli:

dotnet tool update --global Volo.Abp.Studio.Cli

Then try to open abp suite

abp suite

⚠️ Make sure you're logged in ABP CLI or ABP Studio. you can check if you're authenticated or not via following command:

abp login-info

If you're not logged in, use abp login command

Additionally, it is expected that solutions cannot be created on Suite. You can now use ABP Studio to create new solutions after the prerequisites have been installed. See more: https://abp.io/docs/latest/get-started

Thanks for the follow-up — and enjoy your holiday!

You're right, we can't control how users organize their files, and your case clearly highlights that. We'll look into making this part more fault-tolerant, as you suggested. For now, no need to inspect your system — your explanation is already very helpful.

Thanks again!

Thank you for your feedback.

Actually, this behavior is the result of a design decision. ABP Studio relies on certain conventions and file/folder structures when opening a solution. This may feel strict, but it allows Studio to provide a consistent and automated experience across different setups.

We can think of it like how project references work in .csproj files. You can add a reference to another project, but if the file path is incorrect or that project is later moved or renamed, the build will fail. Similarly, Studio needs to resolve some paths and metadata correctly to function as expected — otherwise, it may not behave reliably.

That said, your feedback is valid, and we’ll consider how we can improve Studio’s resilience in future versions.