# Conflicts: # npm/ng-packs/package.json # npm/ng-packs/packages/oauth/package.json # npm/ng-packs/packages/theme-shared/package.json # templates/app-nolayers/angular/package.json # templates/app/angular/package.json # templates/module/angular/package.jsonpull/23220/head
erdemcaygor
7 months ago
@ -0,0 +1,97 @@ |
|||
# Announcing ABP Studio 1.0 General Availability 🚀 |
|||
|
|||
It's the moment you've been waiting for! We are thrilled to announce the stable release of ABP Studio v1.0. This milestone marks a significant step forward in our mission to provide a first-class, integrated development environment for ABP developers. Paired with the recently released [ABP v9.2](https://abp.io/community/articles/announcing-abp-9-2-stable-release-061qmtzb), ABP Studio v1.0 brings new features and improvements that will make your development work faster and more efficient. |
|||
|
|||
For the past several months, our core ABP team has been hard at work, focusing on the features that matter most to you, our community of developers. This release is the peak of that effort, bringing a host of improvements and new capabilities to the forefront. Let's dive in and explore what's new in ABP Studio v1.0. |
|||
|
|||
## What's New with ABP Studio v1.0? |
|||
|
|||
ABP Studio v1.0 is all about enhancing your development experience, from project creation to deployment. Here, we'll walk you through some of the latest features we've implemented, along with other key enhancements that make this release truly special. |
|||
|
|||
### ❤️ Solution Runner with Ready/Health Checks |
|||
|
|||
ABP Studio's Solution Runner now provides visual health monitoring that makes tracking your applications' status easily. When you start an application, a spinner indicates it's "starting", then in the *Overall* tab, you can see the application's health (✅ for healthy, ⚠️ for unhealthy) that displays real-time health status: |
|||
|
|||
 |
|||
|
|||
With [pre-configured health checks](https://abp.io/docs/9.2/solution-templates/layered-web-application/health-check-configuration) in ABP solution templates including database connectivity tests, you get instant feedback on your applications' health. |
|||
|
|||
When health check UI is configured, you can access comprehensive health dashboards with a dedicated "Browse Health UI" command or see the last health response from the "Show Latest Health Check Response" command: |
|||
|
|||
 |
|||
|
|||
When you restart applications that are open in your browser, ABP Studio automatically refreshes the pages for you. |
|||
|
|||
### 🎨 Theme Style Selection on Project Creation |
|||
|
|||
When creating a new solution, you can now choose your theme, theme style, and layout right from the project creation wizard instead of having to configure these settings later. ABP Studio lets you pick from [ABP's officially provided themes including Basic, LeptonX Lite, and LeptonX](https://abp.io/docs/latest/ui-themes). |
|||
|
|||
 |
|||
|
|||
If you select Basic or LeptonX Lite themes, only the theme will be changed. However, if you select the LeptonX theme, you'll get additional options to fine-tune your setup: |
|||
|
|||
- **Theme Style Configuration** - Pick from **System, Light, Dim, or Dark** styles to match how you like your development environment |
|||
- **Layout Options** - **Sidebar menu** / **Top menu** |
|||
|
|||
### 📦 "Container" Application Type for Solution Runner |
|||
|
|||
ABP Studio v1.0 introduces a dedicated "Container" application type that gives you better control over your Docker containers directly from the Solution Runner. Instead of managing all your containers through PowerShell scripts or running them all together, you can now see and control each container individually in the Solution Runner panel. |
|||
|
|||
 |
|||
|
|||
This new feature replaces the previous _Infrastructure_ folder approach with a cleaner, more intuitive container section. You can now: |
|||
|
|||
- **Start and stop containers individually** - No more starting all containers at once when you only need specific services |
|||
- **Monitor container status** - See which containers are running, stopped, or have issues directly in the UI |
|||
- **Manage container dependencies** - Control the order and timing of container startup based on your application needs |
|||
|
|||
Whether you're working with databases, message brokers, or other containerized services, the new Container application type makes it much easier to manage your development environment. This is especially useful for microservice architectures where you might want to run only specific services during development or testing. |
|||
|
|||
### ⚙️ Handle Multiple DbContexts When Adding/Removing/Applying Migrations |
|||
|
|||
When working with ABP solutions that have multiple DbContexts (such as when using the separate tenant database option), ABP Studio now intelligently prompts you to select the appropriate DbContext for migration operations. This enhancement ensures you're always working with the correct database context and helps prevent common mistakes when managing multiple databases. |
|||
|
|||
 |
|||
|
|||
The context selection dialog appears automatically when you perform any of these Entity Framework operations: |
|||
|
|||
- **Adding a new migration** - Choose which DbContext the new migration should target |
|||
- **Removing an existing migration** - Select the DbContext from which to remove the migration |
|||
- **Updating the database** - Specify which database context should be updated |
|||
|
|||
## Get Started with ABP Studio v1.0 Today! |
|||
|
|||
ABP Studio v1.0 is built on the solid foundation of the [latest version of ABP Framework, which is v9.2](https://abp.io/community/articles/announcing-abp-9-2-stable-release-061qmtzb). This means that when you create a new project with ABP Studio, you're getting all the latest features, performance improvements, and bug fixes that come with v9.2. This includes updates to dependencies, enhancements to the core framework, and improvements to application modules. |
|||
|
|||
We are incredibly excited for you to get your hands on ABP Studio v1.0. We believe these new features will make a real difference in your day-to-day development workflow. |
|||
|
|||
### ⬇️ Download ABP Studio 1.0 |
|||
|
|||
Ready to get started? You can download the stable v1.0 release right now from the official ABP Studio website: **[https://abp.io/studio](https://abp.io/studio)** |
|||
|
|||
 |
|||
|
|||
If you are an existing ABP Studio user, it's even easier. You don't need to download the installer again. Simply launch ABP Studio, and it will prompt you to update to the latest version directly from the UI. |
|||
|
|||
> Alternatively, you can click to the *Help -> Check for Updates* context menu item to check for updates and install the latest version: |
|||
> |
|||
>  |
|||
|
|||
### 🔮 What's Next? |
|||
|
|||
ABP Studio v1.0 represents just the beginning of our journey. We're committed to continuously evolving the platform, adding features that directly address real-world development challenges and enhance your workflow. Our goal is to make ABP Studio the go-to development environment for .NET and ABP Framework developers. |
|||
|
|||
We will keep releasing new versions with exciting features based on our roadmap and your valuable feedback. To give you a sneak peek into what's planned for future releases, you can expect to see: |
|||
|
|||
- **Environment Variable Management:** A dedicated UI to easily manage environment variables for your solutions. |
|||
- **OpenTelemetry Integration:** We'll be integrating OpenTelemetry support directly into the startup templates, making distributed tracing and observability a seamless part of your application from day one. |
|||
- **LeptonX Theme Builder**: Allowing users to determine styling, colour palette and easily override their project's theme styles. |
|||
- **Monitor dashboards of the tools used in the solution (e.g. Kubernetes, Redis, Grafana, etc...)** |
|||
- **Pre-configured .NET Aspire for the Microservice Startup Template** |
|||
- **and more...** |
|||
|
|||
We are incredibly excited about the future of ABP Studio and can't wait to share the next set of features with you. Your comments and suggestions are invaluable to us. If you have any feedback, please drop a comment below. |
|||
|
|||
Thank you for being part of our community and happy coding! |
|||
|
|||
**The Volosoft Team** |
|||
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 282 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 455 KiB |
|
After Width: | Height: | Size: 207 KiB |
|
After Width: | Height: | Size: 913 KiB |
|
After Width: | Height: | Size: 53 KiB |
|
After Width: | Height: | Size: 107 KiB |
|
After Width: | Height: | Size: 30 KiB |
@ -0,0 +1,93 @@ |
|||
# Solving MongoDB GUID Issues After an ABP Framework Upgrade |
|||
|
|||
So, you've just upgraded your ABP Framework application to a newer version (like v9.2.0+) and suddenly, your application can't read data from its MongoDB database. You're seeing strange deserialization errors, especially related to `Guid` types. What's going on? |
|||
|
|||
You've likely run into a classic compatibility issue with the MongoDB .NET driver. |
|||
|
|||
### The Problem: Legacy vs. Standard GUIDs |
|||
|
|||
Here's the short version: |
|||
|
|||
* **Old MongoDB Drivers** (used in older ABP versions) stored `Guid` values in a format called `CSharpLegacy`. |
|||
* **New MongoDB Drivers** (v3.0+), now default to a universal `Standard` format. |
|||
|
|||
When your newly upgraded app tries to read old data, the new driver expects the `Standard` format but finds `CSharpLegacy`. The byte orders don't match, and... boom. Deserialization fails. |
|||
|
|||
The ABP Framework team has an excellent official guide covering this topic in detail. We highly recommend reading their **[MongoDB Driver 2 to 3 Migration Guide](https://abp.io/docs/latest/release-info/migration-guides/MongoDB-Driver-2-to-3)** for a full understanding. |
|||
|
|||
Our tip below serves as a fast, application-level fix if you need to get your system back online quickly without performing a full data migration. |
|||
|
|||
### The Quick Fix: Tell the Driver to Use the Old Format |
|||
|
|||
Instead of changing your data, you can simply tell the new driver to continue using the old `CSharpLegacy` format for all `Guid` and `Guid?` properties. This provides immediate backward compatibility without touching your database. |
|||
|
|||
It’s a simple, two-step process. |
|||
|
|||
#### Step 1: Create a Custom Convention |
|||
|
|||
First, create this class in your `.MongoDb` project. It tells the serializer how to handle `Guid` types. |
|||
|
|||
```csharp |
|||
using MongoDB.Bson; |
|||
using MongoDB.Bson.Serialization; |
|||
using MongoDB.Bson.Serialization.Conventions; |
|||
using MongoDB.Bson.Serialization.Serializers; |
|||
using System; |
|||
|
|||
public class LegacyGuidConvention : ConventionBase, IMemberMapConvention |
|||
{ |
|||
public void Apply(BsonMemberMap memberMap) |
|||
{ |
|||
if (memberMap.MemberType == typeof(Guid)) |
|||
{ |
|||
memberMap.SetSerializer(new GuidSerializer(GuidRepresentation.CSharpLegacy)); |
|||
} |
|||
else if (memberMap.MemberType == typeof(Guid?)) |
|||
{ |
|||
var guidSerializer = new GuidSerializer(GuidRepresentation.CSharpLegacy); |
|||
var nullableGuidSerializer = new NullableSerializer<Guid>(guidSerializer); |
|||
memberMap.SetSerializer(nullableGuidSerializer); |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
|
|||
#### Step 2: Register the Convention at Startup |
|||
|
|||
Now, register this convention in your `YourProjectMongoDbModule.cs` file. Add this code to the top of the `ConfigureServices` method. This ensures your rule is applied globally as soon as the application starts. |
|||
|
|||
```csharp |
|||
using Volo.Abp.Modularity; |
|||
using MongoDB.Bson.Serialization; |
|||
using MongoDB.Bson.Serialization.Conventions; |
|||
|
|||
public class YourProjectMongoDbModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
// Fix Start |
|||
var conventionPack = new ConventionPack { new LegacyGuidConvention() }; |
|||
ConventionRegistry.Register( |
|||
"LegacyGuidConvention", |
|||
conventionPack, |
|||
t => true); // Apply to all types |
|||
// Fix End |
|||
|
|||
// ... Your existing ConfigureServices code |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### An Alternative to Full Data Migration |
|||
|
|||
It's important to note that the method described here is an **application-level fix**. It's a fantastic alternative to performing a full data migration, which involves writing scripts to convert every legacy GUID in your database. |
|||
|
|||
If you are interested in the more permanent, data-centric approach, the ABP.IO community has a detailed guide on [**Migrating MongoDB GUIDs from Legacy to Standard Format**](https://abp.io/community/articles/migrating-mongodb-guids-from-legacy-to-standard-format-mongodb-v2-to-v3-dqwybdtw). |
|||
|
|||
Our quick fix is ideal for getting a system back online fast or when a database migration is too complex. The full migration is better for long-term standards compliance. Choose the path that best fits your project's needs! |
|||
|
|||
### That's It! |
|||
|
|||
Restart your application, and the errors should be gone. Your app can now correctly read its old `Guid` data, and it will continue to write new data in the same legacy format, ensuring consistency. |
|||
|
|||
This approach is a lifesaver for existing projects, saving you from a risky and time-consuming data migration. For brand-new projects, you might consider starting with the `Standard` representation, but for everything else, this is a clean and effective fix. Happy coding! |
|||
@ -0,0 +1,113 @@ |
|||
# 🚀 New in ABP Studio: Modular Docker Container Management |
|||
|
|||
We're excited to announce a new improvement to Docker integration in **ABP Studio**! |
|||
With the latest update, you can now manage Docker containers **individually**, add or remove them dynamically, and launch them **either separately or collectively** — all within the Studio. |
|||
|
|||
 |
|||
|
|||
------ |
|||
|
|||
## 🔄 What Has Changed? |
|||
|
|||
In previous versions, Docker dependencies were handled using a **single `docker-compose.override.yml` file**, which was **automatically generated** when creating a new solution if it is needed. |
|||
|
|||
By default, this file included common development dependencies like PostgreSQL, Redis, RabbitMQ, etc., and was executed through a predefined script named `docker-dependencies` in the Solution Runner. |
|||
|
|||
While this approach worked well for simple setups, it had some limitations: |
|||
|
|||
- All services were bundled into a **single compose file**. |
|||
- Adding or removing services required modifying this central file. |
|||
- It wasn't possible to **start or stop individual containers independently**. |
|||
|
|||
------ |
|||
|
|||
## ✅ What's New? |
|||
|
|||
With the latest ABP Studio update: |
|||
|
|||
- Each Docker container can now be defined in its **own `docker-compose` file**. |
|||
- Compose files can be **added or removed** from the Studio UI. |
|||
- Containers can be: |
|||
- **Started or stopped individually**. |
|||
- **Started/stopped in bulk**. |
|||
- The **Solution Runner** recognizes Docker containers and can run them alongside application projects. |
|||
|
|||
------ |
|||
|
|||
## ⚠️ Important Notes Before You Start |
|||
|
|||
### Required: Use `container_name` for Docker Service Matching |
|||
|
|||
When working with the new modular Docker system in ABP Studio, each service **must define a `container_name`**. |
|||
This name is used by ABP Studio to **identify and map** Docker containers to their corresponding service entries in the Studio UI. |
|||
|
|||
#### Why is this mandatory? |
|||
|
|||
- ABP Studio relies on `container_name` to: |
|||
- Detect whether the service is stopped or continue running. |
|||
- Perform **start**, **stop**, and **status check** operations reliably. |
|||
- Match Studio UI entries with actual running Docker containers. |
|||
- Without a `container_name`, container discovery may fail and **service management features might not work as expected**. |
|||
|
|||
#### Example: |
|||
|
|||
``` |
|||
services: |
|||
redis: |
|||
container_name: redis |
|||
image: redis:7 |
|||
ports: |
|||
- "6379:6379" |
|||
networks: |
|||
- my-network |
|||
``` |
|||
|
|||
> If you do **not** define `container_name`, ABP Studio will be unable to track or control the service properly. |
|||
|
|||
------ |
|||
|
|||
## 📥 Migrating from the Old System |
|||
|
|||
If you're using the old method with a centralized compose file: |
|||
|
|||
Before: |
|||
|
|||
``` |
|||
docker-compose -f docker-compose.override.yml up -d |
|||
``` |
|||
|
|||
Now: |
|||
|
|||
1. Create separate `docker-compose` files for each service |
|||
(e.g., `docker-compose.postgres.yml`, `docker-compose.redis.yml`). |
|||
2. Go to the **Solution Runner tab in ABP Studio**. |
|||
3. Use the **“Add Docker Service”** option in Studio to register each file. |
|||
4. Optionally remove or archive the old monolithic compose file. |
|||
|
|||
> If your original `docker-compose.override.yml` contains multiple services, you can split it into individual files — Docker Compose and ABP Studio both support modular composition. |
|||
|
|||
------ |
|||
|
|||
## ⚙️ Advanced: Shared Network |
|||
|
|||
If your containers need to communicate over a shared network, you can define an external network in each compose file like this: |
|||
|
|||
``` |
|||
networks: |
|||
my-network: |
|||
external: true |
|||
``` |
|||
|
|||
ABP Studio automatically creates the network if they do no exist. But if you like you can create the network once using: |
|||
|
|||
``` |
|||
docker network create my-network |
|||
``` |
|||
|
|||
------ |
|||
|
|||
## 📚 Additional Resources |
|||
|
|||
- Docker Compose Documentation |
|||
- ABP Studio Documentation (link to updated docs when ready) |
|||
- [Report Issues on GitHub](https://github.com/abpframework/abp/issues) |
|||
|
After Width: | Height: | Size: 42 KiB |
|
After Width: | Height: | Size: 76 KiB |
|
After Width: | Height: | Size: 68 KiB |
|
Before Width: | Height: | Size: 200 KiB After Width: | Height: | Size: 141 KiB |
|
Before Width: | Height: | Size: 296 KiB After Width: | Height: | Size: 183 KiB |
@ -0,0 +1,46 @@ |
|||
# ABP Version 9.3 Migration Guide |
|||
|
|||
This document is a guide for upgrading ABP v9.2 solutions to ABP v9.3. There are some changes in this version that may affect your applications, please read it carefully and apply the necessary changes to your application. |
|||
|
|||
## Updated `RabbitMQ.Client` to `7.x` |
|||
|
|||
In this version, we updated `RabbitMQ.Client` to `7.1.2`. [This is a major version update](https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/main/v7-MIGRATION.md) that brings significant improvements to the library: |
|||
|
|||
1. Full async/await support throughout the entire public API and internals |
|||
2. Improved performance and resource utilization |
|||
3. Better error handling and connection management |
|||
|
|||
With this update, you should update your method calls to use the new async/await support (in the RabbitMQ related provider packages). There are some method signature changes and new API calls, aligned with the new API. You can see the internal changes we made in [#22510](https://github.com/abpframework/abp/pull/22510) and make the relevant changes in your code. |
|||
|
|||
## Docs Module: Export as PDF |
|||
|
|||
In this version, we have introduced a new feature to the [Docs Module](../../modules/docs.md) that allows you to export the documentation as a PDF file. (Administrators generate PDF files from the back-office side, and then "Download PDF" button appears on the document system, allowing users to download the compiled documentation as a PDF file.) |
|||
|
|||
While implementing this feature, we have made changes in some services of the Docs Module. Typically, you don't need to make any changes in your code unless you have overridden or used internal services of the Docs Module. |
|||
|
|||
For example, the `ProjectAdminAppService` constructor has been changed to accept a new parameter: |
|||
|
|||
```diff |
|||
public class ProjectAdminAppService : ApplicationService, IProjectAdminAppService |
|||
{ |
|||
public ProjectAdminAppService( |
|||
IProjectRepository projectRepository, |
|||
IDocumentRepository documentRepository, |
|||
IDocumentFullSearch elasticSearchService, |
|||
IGuidGenerator guidGenerator, |
|||
+ IProjectPdfFileStore projectPdfFileStore) |
|||
} |
|||
``` |
|||
|
|||
You can see the all internal changes we made in [#22430](https://github.com/abpframework/abp/pull/22430) and [#22922](https://github.com/abpframework/abp/pull/22922) and make the relevant changes in your code if needed. |
|||
|
|||
## Angular UI: Migrating NPM Packages to Standalone Structure |
|||
|
|||
In this version, we've updated our Angular packages to support the new standalone components architecture. This is a non-breaking change - your existing module-based applications will continue to work without any modifications. However, if you wish to migrate to the standalone approach, [we've provided the necessary updates in our packages](https://github.com/abpframework/abp/pull/22829). |
|||
|
|||
The main changes include: |
|||
- Updated routing configurations to support both module-based and standalone approaches |
|||
- Added support for standalone components in ABP Suite code generation |
|||
- Updated schematics to support both module-based and standalone templates |
|||
|
|||
For detailed migration steps and best practices, please refer to our upcoming documentation and/or blog post. The migration is optional, and you can continue using the module-based approach if you prefer. |
|||
|
After Width: | Height: | Size: 115 KiB |
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 7.2 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 8.5 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 2.6 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 21 KiB |
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 32 KiB |
|
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 82 KiB After Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 53 KiB |
|
Before Width: | Height: | Size: 52 KiB After Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 50 KiB |
|
After Width: | Height: | Size: 41 KiB |
|
Before Width: | Height: | Size: 71 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 3.6 KiB |
|
After Width: | Height: | Size: 8.6 KiB |
|
Before Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 29 KiB |
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 43 KiB |
|
Before Width: | Height: | Size: 147 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
Before Width: | Height: | Size: 67 KiB |
|
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 54 KiB |
|
After Width: | Height: | Size: 7.6 KiB |
|
After Width: | Height: | Size: 67 KiB |
|
After Width: | Height: | Size: 11 KiB |