DEV Community: Alex

WPF - Make Source Code Harder to Mess With

Alex — Wed, 25 Mar 2026 16:09:48 +0000

Context, Please

How can you make your WPF project harder to copy elsewhere, decompile, and modify?

Assumptions

You know what WPF is and have made a WPF project before.

Stealing information from this

Application Protection

Disclaimer

If your program is installed entirely on someone's PC, you can't prevent them from stealing, decompiling, and copying your code. The only thing you can do slow them down by making things more difficult.

Method 1: Encryption Algorithms

Use encryption algorithms (AES, DES, etc.) for sensitive info such as passwords. (Where would you store the key?)

Method 2: Dynamic Code Generation

Not sure what this one is

Code Obfuscation

Basically, making the code harder to read. Not ideal, but could slow a bad actor down.

Dotfuscator

This is the native service that comes with Visual Studio. If you're making commercial software this will cost money.

Additional Methods

Method 1: Strong name

Method 2: Compile relevant method int unmanaged code

According to the post where this case from:

Function: Unmanaged code is generally not decompilable by current decompilation tools.

Condition: You must use VC++.NET unmanaged mode to write dll, and then use VC++ managed mode to build a project to introduce this native code dll. Finally, a Dotnet assembly dll is generated. Then this assembly contains both managed code and unmanaged code.

I think this post is talking about this.

nRF Connect Set Up Board

Alex — Wed, 25 Mar 2026 14:41:08 +0000

Context, Please

nRF Connect is a development platform for microcontroller boards from Nordic.

Install Nordic nRF Connect for VS Code

Alex — Wed, 25 Mar 2026 13:22:17 +0000

Table of Contents

Context, Please
Assumptions
1. Installation
2. Creating an application
3. Building an Application

Context, Please

Nordic is a company that makes embedded Microcontrollers. nRF Connect is their development platform which you can install on the text editor VSCode. This post shows how to do that part.

Assumptions

I am assuming you have worked with VSCode before and know about VSCode extensions.

1. Installation

Install nRF Command line tools
- May be asked to install segger jlink driver - check yes to that
Install nRF Connect SDK
- This is now done through the VS Code extension
Install SDK
- Under the VS Code extension you just installed
- Click Manage SDKs -> install SD
- tag release to install - keep in simple
Enable for workspace only
- extensions icon on sidebar -> gear icon on nrfConnect for VS Code Extension Pack
- Disable -> Enable (workspace)

2. Creating an application

Open nRF connect extension. Here are your options
- Manage toolchains - install new toolchains or revert to old toolchains
- Manage SDKs - install new SDK or revert to old SDK
- Open an existing application
- Create a new application
- Create a new board
- Browse samples
Will "create a new application" for this
- Options
  - Create a blank application
  - Copy a sample
  - Browse application index
- Select "copy a sample"
  - Can sort by the module (to the right of "Create New App from sample")
  - Can filter by boards compatible with the sample
  - Search for the name
  - Will be copying blinky for this
- Enter the directory where you want to create the project

3. Building an Application

Create a build configuration
- Tells the compiler which board files to include in your build
- This making the output compatible with your board

Under "Add Build Configuration"
- Select your development kit
- The configuration for your board is stored in a prj.conf file (which is generated based on your board selection)
  - Can add extra configurations with the "Add Fragments" button
  - Can add arguments with the "Add argument" button
  - Can leave the build directory name as "build"
  - Can enable debugging with "Enable debug options"
Here's how you build

Can also save the build configuration

A Rant about Windows and Printers

Alex — Tue, 24 Mar 2026 17:50:43 +0000

Reading about the history of windows and printer drivers was...enlightening

Windows V3 Printer Driver

This is the classic scenario where you download the printer driver onto your computer
And the printer manufacturers would each create their own (crappy) driver that follows the V3 model
These were fine I guess but vulnerable to this "PrintNightmare" vulnerability so Windows freaked out and made the...

Windows V4 Printer Drivers

Then there was V4 which were apparently more secure but a pain in the BUTT
The way these work is the driver stuff is located on the printer/printer server, not your computer
- Instead Windows will grab the needed driver stuff from the printer/print server
- If Windows says a printer has the "Microsoft enhanced Point and Print driver", that's what that means
- I think you can have a V4 driver on your computer locally if the driver on your computer is the exact same as the printer/print server?
This is honestly confusing

Internet Printing Protocol (the GOAT)

The newest is the "Internet Printing Protocol", which shouldn't require any drivers at all
IPP is from IEEE, not Windows
As of 2026 Windows prefers IPP over V3/V4
- Microsoft's WPP and Universal Print are related to IPP (I think)
- Windows stopped packaging V3/V4 third-party drivers with Windows updates
This is what Apple's AirPrint is based on
The problem is that:
- not all printers support IPP (though most do)
- some printers you have to enable IPP manually
- if there are any settings that the printer manufacturer excluded from IPP then GOOD LUCK BUDDY
In case you can't tell I'm biased towards this one

TLDR; For a while the default was that each printer manufacturer made their own crappy drivers that the user had to deal with. IPP should (hopefully) fix this by being a universal standard. Kinda like RCS but for printing. Just my opinion, subject to change.

Publish WPF Project with Azure DevOps Pipeline

Alex — Tue, 24 Mar 2026 14:25:24 +0000

Table of Contents

What Does Any Of This Mean?
trigger, pool, variables
DotNetCoreCLI@2
- command
- projects
- zipAfterPublish
Publish Artifacts aka Spit Out The Files You Want
- Step 1: Publish Output
- Step 2: PublishBuildArtifacts@1
- Settings UI
PowerShell@2
Troubleshooting
- Can't create two projects at a time
- Not found PathToPublish

Context, Please

For context, Azure DevOps is a service from Microsoft that lets you store the history of your code (version control) and add processes for automatically publishing software files (e.g. .exe files) to download.

A pipeline is how you can add automated steps to build your project, and publish .exe files that your computer can run, for example.

This post is for creating a pipeline using YAML in Azure DevOps, specifically, YAML being a file type. I'm assuming you've gotten to the point where you have a blank or template YAML file for your pipeline.

Assumptions

I am assuming you know:

What Git is
What Git branches are
Developing in .NET WPF

I am also assuming you have Azure DevOps set up.

trigger, pool, variables

trigger:
  - master

pool:
  name: Default
  demands:
    - Agent.OS -equals Windows_NT

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  buildRuntime: 'win-x64'
  buildFramework: 'net10.0-windows10.0.19041.0'
  system.debug: 'true' 
  # setting system.debug to true will let you see more output info

Trigger - specifies which branch will cause the pipeline to run
pool - a pool contains a collection of agents, each agent is a piece of software running on a machine, virtual or otherwise (this is set up for my at my company, though setting this up is probably an article of its own)
demands - basically saying the agent pool HAS to be able to handle these things (Windows_NT in this case)
variables - don't overthink this; it's literally just variables. These will get used later

DotNetCoreCLI@2

- task: DotNetCoreCLI@2
  displayName: 'Publish Example Project'
  inputs:
    command: publish
    projects: '*/Example_Project_Name.csproj'
    publishWebProjects: false
    arguments: '--configuration $(buildConfiguration) 
      --runtime $(buildRuntime) 
      --framework $(buildFramework)
      --self-contained 
      --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: true

According to Microsoft, DotNetCoreCLI@2 is used to: "Build, test, package, or publish a .NET application, or run a custom .NET CLI command."

The @2 is the version number for this command. It used to be @1 and may change to @3 at some point.

command

projects

According to Microsoft:

projects - Path to project(s) or solution(s)
string. Optional. Use when command = build || command = restore || command = run || command = test || command = custom || publishWebProjects = false.

The path to the .csproj or .sln file(s) to use. You can use wildcards (e.g. **/*.csproj for all .csproj files in all subfolders). For more information, see the file matching patterns reference.

If there are multiple projects in the solution, put "**/placeholder_text.csproj", otherwise put "*/placeholder_text.csproj". I think, not 100% sure here. You may have to play around with this and you may throw a "can't create two projects at a time" error.

This path is relative to the root of the repository regardless of the workingDirectory setting.

By default, workingDirectory is $(System.DefaultWorkingDirectory)

zipAfterPublish

Set this to true, unless you have another dedicated way you would like to publish this.

Publish Artifacts aka Spit Out The Files You Want

There are two arguments involved with publishing the artifacts:

The "publish" command
1. Will build and publish the project
2. The "output" argument tells the command where to place the files
The "PublishBuildArtifacts" task
1. Will pick up and spit out the specified files onto the "Build Artifacts" area (where you can download them!)
2. The "pathToPublish" input tells the task where to pick up the files

Both the "output" argument and the "pathToPublish" should be based on the "$(Build.ArtifactStagingDirectory).

To figure out where the build/publish command is placing files, check:

The "output" argument for the build/publish command
The command line output for the build/publish step on the DevOps page

AbbottLabsControllerTester -> C:\agent_filepath_goes_here\s\...
AbbottLabsControllerTester -> C:\agent_filepath_goes_here\a\output_argument_will_be_here

The location for the ArtifactStagingDirectory is

C:\agent_filepath_goes_here\a

Step 1: Publish Output

- task: DotNetCoreCLI@2
  displayName: 'Publish project'
  inputs:
    command: 'publish'
    projects: '$(project)'
    publishWebProjects: false
    arguments: '--configuration $(buildConfiguration) 
      --runtime $(buildRuntime) 
      --self-contained 
      --output $(Build.ArtifactStagingDirectory)\Example_Project_V$(Build.BuildNumber)
      --framework $(buildFramework)'
    zipAfterPublish: true
    modifyOutputPath: false

I recommend setting "modifyOutputPath" to false. If "modifyOutputPath" is set to true, the .zip folder will just have the project name and not the custom name you may want to have. StackOverflow post to back me up

If modifyOutputPath: true

...\a\Abbott_Labs_Tester_V20260324.26\AbbottLabsControllerTester\

ExampleProject Published Files
- Example_Project_V20260324.30
  - ExampleProjectName.zip (project files are in here)

If modifyOutputPath: false

...\a\Abbott_Labs_Tester_V20260324.32\

ExampleProject Published Files
- Example_Project_V20260324.30
  - Example_Project_V20260324.30.zip (project files are in here)

Step 2: PublishBuildArtifacts@1

It's not enough to just publish/create the outputs, you need to tell the pipeline to spit them out for you to download.

task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: '$(Build.ArtifactStagingDirectory)'
    artifactName: 'ExampleProject Published Files'

Important notes:

pathToPublish tells the pipeline where to look for the files
- if there's nothing there it will throw a warning and there will be no artifacts
Both the "pathToPublish" and "artifactName" are required.
Note! Don't forget the "." in Build.ArtifactStagingDirectory!

Settings UI

You can also add tasks through the UI on DevOps.
If you click on the little gray "settings" text above yaml commands it will show you the settings for said command.

PowerShell@2

I'm not worrying about this for my project but I figured I'd write it down at least.

- task: PowerShell@2
  displayName: 'Build Setup'
  inputs:         
    targetType: 'filePath'
    filePath: '$(Build.Repository.LocalPath)\DTC Software\AW_DTC\buildSetup.ps1'
    arguments: '-publishDirPath "$(Build.ArtifactStagingDirectory)\PLACEHOLDER_TEXT"
      -publishZipPath "$(Build.ArtifactStagingDirectory)\Zip"
      -publishSetupPath "$(Build.ArtifactStagingDirectory)\Setup" 
      -nsiFilePath "$(Build.Repository.LocalPath)\DTC Software\AW_DTC\AW_DTC.nsi"'
    workingDirectory: '$(Build.ArtifactStagingDirectory)'

The parameters such as publishZipPath are custom to the powershell file.

Troubleshooting

Can't create two projects at a time

Under your publish step, make sure the filepath to your .csproj file is correct.

Not found PathToPublish

The PublishBuildArtifacts has a "pathToPublish" input that tells PublishBuildArtifacts where to look. If the path specified in "pathToPublish" does not exist, this will get thrown.