WinForm应用开机自启动避坑指南:从注册表到JSON配置的完整流程

C#实现应用程序自启动的几种方法(winform为例) 在工业领域,部分项目要求开发者增加软件开机自启动功能。这里大概有两种方法来实现这一功能,这里我们以winform桌面应用程序为例,采用第一种方法:修改注册表的形式来实现这一功能1.修改计算机注册表的方式2.将软件的快捷方式创建到计算机的自动启动目录下提示:以下是本篇文章正文内容,下面案例可供参考// 获取带有可执行文件名字的的路径elserk.Close();// 将checkbox的勾选结果持久化到json文件中经过楼主测试,上述代码已经在楼猪电脑上测试成功 ,o( 阅读详情

WinForm应用开机自启动避坑指南:从注册表到JSON配置的完整流程

你是否遇到过这样的场景:辛苦开发的工业控制上位机软件,部署到现场后,客户反馈说“电脑重启后软件没自动起来”,或者“那个开机自启动的勾选框,点了好像没用”?对于C# WinForm开发者而言,实现一个稳定可靠的开机自启动功能,远不止在注册表里写个键值那么简单。这背后涉及到权限的博弈、配置的持久化、异常的处理,以及如何在用户无感的情况下,让应用优雅地“活”在系统启动项里。很多教程只告诉你“怎么做”,却很少深入剖析“为什么这么做”以及“可能会遇到什么坑”。今天,我们就来彻底拆解这个功能,从最基础的注册表操作,到结合JSON配置文件的完整解决方案,一步步带你绕过那些开发中常见的“暗礁”,打造一个健壮、可维护的自启动模块。

1. 理解自启动的核心机制与权限迷宫

开机自启动,本质上就是告诉操作系统:“嘿,下次启动时,记得帮我运行这个程序。”在Windows世界里,主要有两条主流路径:注册表启动项和启动文件夹快捷方式。对于需要较高稳定性、尤其是工业后台服务类的WinForm应用,修改注册表是更常见、也更可控的选择。

注册表路径通常有两个关键位置:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (简称HKLM)
  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (简称HKCU)

它们的区别,直接决定了你遇到的第一个大坑:权限。

注册表位置作用范围所需权限稳定性常见问题
HKLM对所有用户生效需要管理员权限高,系统级设置在非管理员账户或UAC开启时,写入操作会失败或触发权限提示。
HKCU仅对当前用户生效普通用户权限即可依赖用户登录如果软件配置为以系统服务或其他用户身份运行,则不会触发自启动。

注意:现代Windows系统(如Win10/11)普遍启用了用户账户控制(UAC)。即使你是管理员组成员,直接写入HKLM也可能被UAC拦截,导致程序抛出UnauthorizedAccessException异常。这是很多自启动功能“时灵时不灵”的根源。

所以,在动手写代码前,先想清楚:你的软件是为单用户设计的,还是需要为所有用户开机启动?如果是后者,就必须处理权限提升问题。一个更稳妥的实践是,优先考虑使用HKCU路径,除非有明确的、必须为所有用户服务的需求。这样能避免大量兼容性问题。我们的方案也将以HKCU为基础展开。

2. 构建可配置的自启动管理模块

一个优秀的功能不能是“一锤子买卖”。用户今天勾选自启动,明天可能又想取消。我们需要一个能记住用户选择,并且能随时响应用户操作的交互模块。这通常由一个CheckBox控件和背后的配置管理逻辑组成。

2.1 设计配置存储:为什么选择JSON?

配置需要持久化,下次启动软件时,CheckBox应该能自动恢复到上次设置的状态。存储方式有很多:XML、INI、甚至数据库。这里我们选择JSON,原因如下:

  • 结构清晰:天然支持键值对和嵌套,可读性好。
  • 流行度高:.NET生态(尤其是Newtonsoft.Json或System.Text.Json)支持完善,序列化/反序列化极其方便。
  • 轻量:文件小巧,读写速度快。

假设我们在项目根目录创建一个appsettings.json文件,初始内容如下:

{
  "AutoLaunchEnabled": false,
  "WindowTopMost": true,
  "LastConfigVersion": "1.0"
}

AutoLaunchEnabled 就是我们用来控制自启动开关的配置项。

2.2 实现配置的读取与回显

在窗体加载事件(Form_Load)中,我们需要读取JSON配置,并据此设置CheckBox的初始状态。这里的关键是健壮的读取逻辑。

private bool LoadAutoLaunchSetting()
{
    string configPath = Path.Combine(Application.StartupPath, "appsettings.json");
    
    // 如果配置文件不存在,则创建默认配置
    if (!File.Exists(configPath))
    {
        var defaultSettings = new { AutoLaunchEnabled = false, WindowTopMost = true };
        string defaultJson = JsonConvert.SerializeObject(defaultSettings, Formatting.Indented);
        File.WriteAllText(configPath, defaultJson);
        return false;
    }

    try
    {
        string jsonContent = File.ReadAllText(configPath);
        dynamic config = JsonConvert.DeserializeObject(jsonContent);
        
        // 安全地获取配置值,如果不存在则返回默认值false
        return config?.AutoLaunchEnabled ?? false;
    }
    catch (Exception ex)
    {
        // 记录日志,并返回安全默认值
        // Logger.Error($"读取配置文件失败: {ex.Message}");
        return false;
    }
}

private void MainForm_Load(object sender, EventArgs e)
{
    // 初始化UI状态
    chkAutoStart.Checked = LoadAutoLaunchSetting();
}

这段代码做了几件重要的事:

  1. 检查文件存在性:避免因文件丢失导致崩溃。
  2. 异常处理:文件读取或JSON解析可能出错,必须用try-catch包裹,保证程序不会因此卡死。
  3. 提供默认值:使用空值合并运算符(??),确保即使配置项缺失,也有一个安全的默认状态。

3. 打通注册表操作与配置持久化

这是最核心的部分:当用户点击CheckBox时,我们需要同步完成两件事:1. 修改注册表;2. 更新JSON配置文件。

3.1 安全的注册表写入操作

让我们为CheckBox的CheckedChanged事件编写处理逻辑。记住,我们选择对当前用户生效的HKCU路径,以规避权限问题。

private void chkAutoStart_CheckedChanged(object sender, EventArgs e)
{
    bool enableAutoStart = chkAutoStart.Checked;
    string appName = "MyWinFormApp"; // 建议使用固定应用名,而非可执行文件名
    string appPath = Application.ExecutablePath; // 获取当前exe的完整路径

    // 注册表路径
    string regKeyPath = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Run";
    
    try
    {
        using (RegistryKey key = Registry.CurrentUser.OpenSubKey(regKeyPath, true))
        {
            // 如果键不存在,OpenSubKey可能返回null,需要创建
            if (key == null)
            {
                using (RegistryKey newKey = Registry.CurrentUser.CreateSubKey(regKeyPath))
                {
                    UpdateRegistryValue(newKey, appName, appPath, enableAutoStart);
                }
            }
            else
            {
                UpdateRegistryValue(key, appName, appPath, enableAutoStart);
            }
        }
        
        // 注册表操作成功后,立即更新配置文件
        SaveAutoLaunchSetting(enableAutoStart);
        
        // 给用户一个友好的反馈
        string status = enableAutoStart ? "已启用" : "已禁用";
        // MessageBox.Show($"开机自启动{status}。", "提示", MessageBoxButtons.OK, MessageBoxIcon.Information);
    }
    catch (UnauthorizedAccessException)
    {
        // 虽然用了HKCU,但在极端权限配置下仍可能失败
        MessageBox.Show("无法修改启动项设置,请检查用户权限。", "错误", MessageBoxButtons.OK, MessageBoxIcon.Error);
        chkAutoStart.Checked = !enableAutoStart; // 回滚UI状态
    }
    catch (Exception ex)
    {
        MessageBox.Show($"操作失败: {ex.Message}", "错误", MessageBoxButtons.OK, MessageBoxIcon.Error);
        chkAutoStart.Checked = !enableAutoStart;
    }
}

// 辅助方法:更新注册表键值
private void UpdateRegistryValue(RegistryKey key, string valueName, string appPath, bool enable)
{
    if (enable)
    {
        // 写入:将应用路径设置为该键的值
        key.SetValue(valueName, appPath, RegistryValueKind.String);
    }
    else
    {
        // 禁用:删除该键(如果存在)
        if (key.GetValue(valueName) != null)
        {
            key.DeleteValue(valueName, false);
        }
    }
}

提示:注册表操作是敏感的,务必使用using语句确保RegistryKey对象被正确关闭和释放,避免资源泄漏。另外,使用固定的appName(如“MyWinFormApp”)比使用可变的execFileName更好,这样即使你的exe文件改名了,也能在注册表中准确找到并管理自己的启动项。

3.2 同步更新JSON配置文件

注册表操作成功后,需要将最新的选择保存到JSON文件,保证状态持久化。

private void SaveAutoLaunchSetting(bool isEnabled)
{
    string configPath = Path.Combine(Application.StartupPath, "appsettings.json");
    JObject configJson;

    // 读取现有配置
    if (File.Exists(configPath))
    {
        string existingJson = File.ReadAllText(configPath);
        configJson = JObject.Parse(existingJson);
    }
    else
    {
        configJson = new JObject();
    }

    // 更新配置项
    configJson["AutoLaunchEnabled"] = isEnabled;

    // 写回文件(使用缩进格式,便于阅读)
    string updatedJson = configJson.ToString(Formatting.Indented);
    File.WriteAllText(configPath, updatedJson);
}

这里使用了Newtonsoft.Json.Linq中的JObject,它提供了非常灵活的方式来动态修改JSON对象,无需预定义强类型模型。

4. 应对进阶场景与疑难杂症

基础功能跑通了,但在真实的生产环境中,我们还会遇到更复杂的情况。

4.1 处理带参数启动的应用

如果你的应用启动时需要附加命令行参数,注册表里的路径就需要包含这些参数。例如,你的应用需要以MyApp.exe -minimized方式启动。

string appPathWithArgs = $"\"{Application.ExecutablePath}\" -minimized -config=\"C:\\config.xml\"";
key.SetValue(appName, appPathWithArgs, RegistryValueKind.String);

注意:路径和参数中包含空格时,务必用双引号包裹整个字符串,否则系统解析时会出错。上面的例子展示了正确的格式。

4.2 应对杀毒软件或系统优化的误杀

这是非常现实的问题。某些安全软件或“电脑管家”类工具,会将未经它们认证的、修改注册表启动项的行为视为风险,并可能静默删除你写入的键值。

应对策略:

  • 使用数字签名:为你的应用程序购买并添加有效的代码签名证书,能极大增加安全软件的信任度。
  • 用户引导:在软件首次设置自启动时,可以提示用户:“如果开机后软件未自动启动,请检查XX安全软件是否阻止了本程序的启动项。”
  • 启动时自检:可以在软件主逻辑启动时,添加一个简单的自检,检查注册表中自己的启动项是否还存在。如果不存在,而本地配置又显示为“启用”,则可以记录日志或温和地提示用户。
private bool IsAutoStartKeyPresent()
{
    string regKeyPath = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Run";
    string appName = "MyWinFormApp";
    
    using (RegistryKey key = Registry.CurrentUser.OpenSubKey(regKeyPath, false))
    {
        if (key != null)
        {
            return key.GetValue(appName) != null;
        }
    }
    return false;
}

4.3 为安装程序集成自启动选项

如果你的软件通过安装包(如MSI)部署,更专业的做法是在安装过程中让用户选择是否开机启动,并由安装程序(拥有更高权限)直接写入HKLM注册表。这通常需要在安装项目(如WiX Toolset或InstallShield)中自定义操作来实现。对于绿色软件或需要用户灵活控制的场景,本文所述的运行时配置方案则更为合适。

5. 完整代码结构与最佳实践梳理

让我们把上面的碎片整合起来,形成一个清晰、可复用的自启动管理类。将逻辑与UI分离是更好的架构。

// AutoStartManager.cs
using Microsoft.Win32;
using Newtonsoft.Json.Linq;
using System;
using System.IO;

namespace MyApp.Utilities
{
    public class AutoStartManager
    {
        private const string AppName = "MyWinFormApp";
        private const string ConfigFileName = "appsettings.json";
        private readonly string _appPath;
        private readonly string _configFilePath;

        public AutoStartManager()
        {
            _appPath = Application.ExecutablePath;
            _configFilePath = Path.Combine(Application.StartupPath, ConfigFileName);
        }

        // 检查当前是否已启用自启动
        public bool IsEnabled()
        {
            string regKeyPath = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Run";
            using (RegistryKey key = Registry.CurrentUser.OpenSubKey(regKeyPath, false))
            {
                return key?.GetValue(AppName) != null;
            }
        }

        // 从配置文件加载设置(用于初始化UI)
        public bool LoadSettingFromConfig()
        {
            if (!File.Exists(_configFilePath)) return false;

            try
            {
                string json = File.ReadAllText(_configFilePath);
                var config = JObject.Parse(json);
                return config["AutoLaunchEnabled"]?.Value<bool>() ?? false;
            }
            catch
            {
                return false;
            }
        }

        // 启用或禁用自启动
        public bool SetAutoStart(bool enable, string commandLineArgs = "")
        {
            string regKeyPath = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Run";
            string valueData = string.IsNullOrEmpty(commandLineArgs) ? _appPath : $"\"{_appPath}\" {commandLineArgs}";

            try
            {
                using (RegistryKey key = Registry.CurrentUser.OpenSubKey(regKeyPath, true))
                {
                    if (key == null)
                    {
                        using (var newKey = Registry.CurrentUser.CreateSubKey(regKeyPath))
                        {
                            UpdateRegistry(newKey, enable, valueData);
                        }
                    }
                    else
                    {
                        UpdateRegistry(key, enable, valueData);
                    }
                }

                // 更新配置文件
                SaveSettingToConfig(enable);
                return true;
            }
            catch (Exception ex)
            {
                // 记录日志 ex.Message
                return false;
            }
        }

        private void UpdateRegistry(RegistryKey key, bool enable, string valueData)
        {
            if (enable)
            {
                key.SetValue(AppName, valueData, RegistryValueKind.String);
            }
            else
            {
                if (key.GetValue(AppName) != null)
                {
                    key.DeleteValue(AppName);
                }
            }
        }

        private void SaveSettingToConfig(bool isEnabled)
        {
            JObject configJson;
            if (File.Exists(_configFilePath))
            {
                configJson = JObject.Parse(File.ReadAllText(_configFilePath));
            }
            else
            {
                configJson = new JObject();
            }
            configJson["AutoLaunchEnabled"] = isEnabled;
            File.WriteAllText(_configFilePath, configJson.ToString(Newtonsoft.Json.Formatting.Indented));
        }
    }
}

然后在你的主窗体中,可以这样简洁地使用:

// MainForm.cs
private AutoStartManager _autoStartManager;

private void MainForm_Load(object sender, EventArgs e)
{
    _autoStartManager = new AutoStartManager();
    chkAutoStart.Checked = _autoStartManager.LoadSettingFromConfig();
}

private void chkAutoStart_CheckedChanged(object sender, EventArgs e)
{
    bool success = _autoStartManager.SetAutoStart(chkAutoStart.Checked);
    if (!success)
    {
        MessageBox.Show("设置失败,请以管理员身份运行或检查权限。");
        chkAutoStart.Checked = !chkAutoStart.Checked; // 回滚
    }
}

最后,别忘了在项目中通过NuGet安装Newtonsoft.Json包,这是处理JSON的利器。在实际项目中,我习惯将AutoStartManager类放在一个独立的工具类库中,这样其他项目也能方便地引用。记住,处理系统级功能时,异常处理和日志记录是你的好朋友,它们能帮助你在出现问题时快速定位,而不是让用户面对一个莫名其妙的崩溃窗口。

Winform中设置程序开机自启动(修改注册表和配置自启动快捷方式) winform程序需要在启动时自启动,可通过将exe快捷方式添加到自启动目录下,或者通过修改注册表添加启动项的方式。 阅读详情

相关推荐

C# WinForm实战:打造桌面日程提醒器,从定时器到开机自启

桌面效率工具的开发中,定时任务与UI线程的协调是常见难点。WinForm作为轻量级桌面应用框架,通过主线程消息循环处理控件更新,能有效避免后台线程直接操作界面引发的刷新卡顿问题。合理选用System.Windows.Forms.Timer,可让定时提醒逻辑与界面交互保持流畅。这类工具在个人日程管理、轻量办公场景中有极高实用价值,尤其适合需要常驻系统托盘、定时弹出提醒的桌面环境。本文以C# WinForm日程提醒器为例,完整展示了从数据模型、提醒引擎到窗体缩放适配、开机自启的实现路径,并针对窗体尺寸适配、托盘

weixin_33423874的博客 222

WinFrom应用程序开机自启动

WinFrom应用程序开机自启动,WinFrom应用程序开机自启动几种方式,我的思路是将启动路径写入注册表,在程序启动时执行将应用写入注册表,在下次重启时则会自动启动。可以自己在应用程序写复选框是否开机自启动,也可以在启动winfrom时,直接执行下面代码。.........

不踩坑,不知道坑有多深;不总结,踩过的坑白踩。 3476

喷涂工艺SCADA上位机:Winform实现的生产级exe系统

SCADA系统是工业自动化中实现数据采集、监控报警、历史追溯与报表输出的核心技术体系;Winform作为成熟稳定的桌面GUI框架,在资源受限、网络不稳、兼容性要求高的车间现场仍具不可替代性。其原理在于依托.NET Framework原生运行时,通过GDI+轻量渲染、内存映射缓存、S7CommPlus协议直连PLC等机制,保障毫秒级响应与断网续传能力。技术价值体现在交付即用(单文件exe)、免环境依赖、低硬件门槛与高鲁棒性,广泛适用于汽车零部件、涂装产线、中小型离散制造等场景。本文详解一个连续稳定运行14个月

weixin_33849215的博客 385

学习ASP.NET Core Blazor编程系列二十六——登录(5)

既然是抽象类,我们需要自定义一个它的子类,由于是模拟登录,进行登录流程的验证,因此我们先来做一个测试的Provider来试试。在webapi出现之后,出现了JWT这样的认证方式,原理大同小异,相同的是, 认证信息都是保存在请求头中传递的,不同是JWT中的认证信息需要编码写入请求头之后再发送请求,不像浏览器,发送请求时会自动带上cookie信息,不需要编码。现在我们已经完成了登录认证的Provider了,接下來要做的事情,就是让我们的页面上的组件,可以获取登录信息,来决定是登录用户是否已经授权。

Gefangenes的博客 2326

C# WinForm实战:198个经典实例源码解析与高频问题避坑指南

WinForm作为C#桌面应用开发的基础框架,至今仍是快速构建内部工具、上位机与维护老系统的常用选择。其核心原理依赖事件驱动与消息循环,控件操作、数据绑定、多线程通信是绕不开的关键技术。理解跨线程UI更新、反射调用、串口通信等机制,能显著提升桌面应用的稳定性和开发效率。在实际工程中,从串口数据帧解析到界面美化,从安装包制作到高DPI适配,这些技术价值直接体现在快速交付可靠工具上。针对开发者高频搜索的C# WinForm实例、串口通信、winform invoke、反射触发Click等真实需求,一份覆盖198

weixin_32288959的博客 223

C# Winform 定时自动清理过期文件工具开发实战

在系统运维和日常使用中,日志、缓存与临时文件常因只增不减而迅速占满磁盘空间。手动清理效率低下,而Windows自带功能又无法覆盖自定义目录。文件清理工具的核心原理是根据文件最后写入时间判断过期,再结合定时任务实现自动化删除,从而有效管理存储资源。此类工具在服务器维护、个人电脑优化及备份目录管理中均有广泛应用,不仅能减少人工干预,还能避免因磁盘空间不足引发的业务故障。本文从文件遍历与日期比较的基础技术出发,介绍如何利用C# Winform开发一款带有图形界面的定时自动清理工具,涵盖界面设计、关键代码、配置持久

weixin_34023982的博客 480

学习ASP.NET Core Blazor编程系列二十二——登录(1)

通过前面的ASP.NET Core Blazor编程系列文章为读者介绍了Blazor及组件的相关基础概念,以及我们已经实现了用Blazor实现对数据的增删改查这四大基本功能,以及文件上传的功能,通过这些功能的实现我们已经能用Blazor处理一些简单的实际问题,特别是企业内部信息管理系统的相关问题。前面的ASP.NET Core Blazor编程系列文章中却没有讲到信息管理系统中一个最基本功能——登录,有关登录功能的介绍。

Gefangenes的博客 1382

C# Winform实现文件夹过期文件自动清理工具详解

在系统运维与日常开发中,临时文件、日志和缓存的无序堆积常常导致磁盘空间告急,手动清理效率低下且存在误删风险。借助C# Winform事件驱动模型与文件系统监听机制,可以构建一款可视化、可配置的文件夹自动清理工具。其核心采用FileSystemWatcher感知文件变化,配合定时器执行周期扫描,依据文件最后写入时间判定过期并安全删除,同时通过白名单、重试机制与完整日志保障操作可靠。该工具适用于日志目录、下载目录、缓存目录等场景,支持界面配置与JSON持久化,编译后双击即用,是提升服务器与本地磁盘管理效率的实用

weixin_34112181的博客 498

C#利用注册表与JSON配置实现WinForm应用开机自启动的完整指南

本文提供了一份C# WinForm应用实现开机自启动的完整指南。核心方案是通过操作Windows注册表实现自启动控制,并利用JSON配置文件持久化用户设置,确保配置、UI与系统状态一致。文章详细讲解了注册表操作原理、JSON配置读写、UI事件绑定以及处理路径变更、权限等常见问题的进阶技巧。

s4t5u6v的博客 894

C# Winform文件夹监控定时清理工具:源码与打包全解析

系统在长时间运行后,磁盘空间被日志文件、临时缓存和下载文件迅速耗尽,是导致服务卡顿甚至崩溃的常见诱因。要避免这类问题,关键在于建立文件生命周期的自动管理机制。本文从文件监控与定时清理的基本概念出发,剖析了基于FileSystemWatcher的事件监听原理,以及定时扫描策略在目录整理中的应用价值,并结合C# Winform技术栈,详细介绍如何设计并实现一个可视化、可配置的文件夹自动清理工具。该工具能够按照文件最后写入时间筛选过期内容,具备回收站保护、异常处理、多目录扩展等能力,同时提供了完整的源码编译与ex

weixin_33755649的博客 458

Winform轻量级SCADA系统:S7-200CN通信与实时监控实战

SCADA系统是工业自动化中实现数据采集、监控与控制的核心技术,其本质在于协议解析、实时性保障与人机交互协同。在老旧产线(如Windows 7工控机、S7-200CN PLC)场景下,传统组态软件因协议支持弱、响应滞后、二次开发封闭而难以落地;而基于.NET Framework的Winform架构凭借低内存占用、高启动速度和强兼容性,成为轻量级SCADA的理想载体。本文聚焦S7-200CN PPI协议直连、Winform Timer精准调度、ChartSurface双缓冲趋势图渲染及PropertyGrid

weixin_30599769的博客 1084

不用管理员权限也能搞定!C# WinForm应用自启动的两种安全实现方案

本文针对C# WinForm应用在无管理员权限下实现自启动的需求,提供了两种安全可靠的解决方案:基于当前用户注册表(HKCU)和利用系统启动目录。文章详细解析了两种方案的实现原理、核心代码、优劣对比及实战注意事项,帮助开发者在不提权的情况下,优雅地实现应用程序自启动,提升用户体验与软件专业性。

pz89012345的博客 170

C# WinForm定时自动删除文件工具:设计原理与工程实践

在系统运维和日常办公中,日志文件、临时缓存与下载残留不断堆积,手工清理耗时费力。定时任务作为自动化运维的基础能力,能够按预设策略定期释放磁盘空间,是提升效率的常用手段。文件清理机制通常涉及执行频率、匹配规则与保留天数三个核心参数,并需结合文件最后修改时间判断是否过期,同时处理好线程安全、文件占用与误删防护等工程细节。Windows环境下,WinForm界面相比控制台或计划任务更直观易用,适合制作轻量级清理工具。该方案可广泛应用于服务器日志归档、内网共享目录维护、个人电脑缓存整理等场景。本文围绕一个C# Wi

weixin_34293059的博客 424

WinForm设置电脑开机自动启动程序

json配置文件: { "ConnectionStrings": { "Default": "Data Source=./print_infos.db;Mode=ReadWriteCreate;Cache=Default;" }, "IsAutoBoot": false, "TopMost": true } 窗体加载事件中,通过读取配置文件得到是否开启开机自动启动,给单选框选中或不选中 ck_Selfstart.Checked=readJson("IsAutoBoot");

hyx1229的博客 3335

用C# WinForms开发定时自动清理过期文件的小工具

磁盘空间紧张常常源于临时文件、日志和备份文件的持续堆积。针对这一场景,定时删除机制结合文件生命周期管理成为高效解决方案。文章从需求边界出发,介绍了如何利用C# WinForms构建可视化配置界面,通过Timer控件实现定时扫描,依据文件最后写入时间判断过期条件,并支持回收站保护和扩展名过滤。同时探讨了.NET Framework 4.7.2与.NET 8的选型权衡,以及框架依赖与自包含发布对分发的实际影响。该方案适用于数据库备份清理、日志滚动和下载目录整理等典型场景,既有实践代码,也有排坑经验,为需要自动化

weixin_33834137的博客 321

双层优化入门(2)—基于yalmip的双层优化求解(附matlab代码)

​上一篇博客介绍了双层优化的基本原理和使用KKT条件求解双层优化的方法,这篇博客将介绍使用yalmip的双层优化问题的求解方法。 1.KKT函数 通过调用yalmip工具箱中的KKT函数,可以直接求出优化问题的KKT条件,省去自己手动写的步骤。 2.solvebilevel函数 solvebilevel是yalmip工具箱内置的求解双层优化问题的函数。也就是通过这个函数,不需要咱手动写KKT条件,也不需要使用KKT函数,直接把上、下层优化的目标函数、约束条件往里面一放,就能求出结果。 ​

配电网和matlab的博客 1万+

博客目录 分类: 其他 2014-07-16 22:...

C# 01.C# SMTP邮件发送02.利用YaHoo YUI实现Javascript CSS 压缩03.IIS日志分析工具04.C# Winform 文件编码批量转换工具05.C# Winform ListView使用06.DbHelper-SQL数据库访问助手07.FileHelper-文件操作辅助类08.AppPoolService-IIS应用程序池辅助类(...

weixin_30627381的博客 182

【大模型应用开发-大模型知识】(二)大模型分类和常见大模型

目前包含 Claude 和 Claude-Instant 两种模型可供选择,其中 Claude Instant 的延迟更低,性能略差,价格比完全体的 Claude-v1 要便宜,两个模型的上下文窗口都是 9000 个token(约 5000 个单词,或 15 页)它的目标是“更安全”、“危害更小”的人工智能。Google 还开发了多种 PaLM 的改进版本。更强大的基础模型: ChatGLM3-6B 的基础模型 ChatGLM3-6B-Base 采用了更多样的训练数据、更充分的训练步数和更合理的训练策略。

1万+

用39台Intel笔记本搭建70B模型分布式推理集群的实战方案

在单机资源受限的情况下,大模型部署往往面临显存与内存的双重瓶颈。模型并行作为一种将计算负载分散到多台设备的分布式推理技术,通过张量并行与流水线并行两种核心策略,把庞大的Transformer模型按层或张量切分,交由不同计算节点协同处理。该方案不仅适用于专业AI服务器,也能在普通设备组成的低成本集群上落地实现。把集群中的每个分片节点视作独立数据源,借助动态注册机制统一调度和健康检查,即可在局域网内构建一个松耦合的推理集群。无论是7B模型的迷你实验,还是70B级模型的多机部署,理解模型分片、节点注册与推理拓扑都

weixin_34080571的博客 287

CMake是什么?为什么学习CMake

CMake的主要作用和重要性,包括其在跨平台构建中的应用、如何支持多种编译器及操作系统,以及它在管理大型和复杂项目中的优势。

小鱼酱的博客 3871

【Unity动画优化插件】BT - OptiAnimX —— AAA级动画优化框架深度剖析

BT - OptiAnimX 是一款面向 Unity 的高性能动画优化框架,核心目标是解决多角色动画场景中的性能瓶颈问题。该插件对标《战争机器5》和《巫师3》等 AAA 游戏中的动画优化技术,通过一整套自动化与智能化的优化策略,将动画性能提升与视觉质量控制结合在一起。它适用于从移动端、VR 到高端 PC 的多平台项目,尤其在“多人角色 + 高频动画”的场景中表现突出,例如 MMO、开放世界、动作游戏等。BT - OptiAnimX 本质上是一套“动画性能调度系统”,而不仅仅是优化工具。

2403_88403568的博客 433
上一篇: 昇腾310 DMA内存分配实战:dma_alloc_attrs的三种核心场景解析
下一篇: 轴承座有限元分析避坑指南:ANSYS静力分析中6个新手最易翻车的细节
linux6sysadmin
博客等级 码龄4年 59粉丝 1615原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值