TLDR Version, we've moving from 2016 to 2023 and have issues with our VSCode setup. We chose (I believe it was from summit) a small app and created a database script to populate it and a zip file that holds the setup document and project code. The long version. We've got questions. Coldfusion Builder is Dead. Long live Coldfusion Builder! We use Coldfusion builder 2016, mostly for debug, and We're moving our codebase to 2023. Not quite as drastic as our move from Coldfusion 8 to 2016, but the timespan is about the same. Unfortunately there is no Coldfusion Builder, and the times we've tried to use the Adobe Coldfusion Builder Extension for VSCode as a replacement have not gone well. We've had a couple of sessions with the developers of the extension from Adobe to show them some of the issues we've experienced, but we have a framework that was developed internally, we also utilize Coldbox and Wirebox and .net user auth piece just for good measure. Everything works well in Coldfusion Builder 2016 and has been, since we moved to it. Our development environment is mostly developer preference, but do have some minimum requirements just to keep apples to apples. It must have the coldfusion server version we're developing for installed locally. We like to have a local database (MS Sql Server Developer Edition and tools preferred, but we also have DEV and TEST platforms we can swap too as well), along with the GIT Desktop, Notepad++ (for data and code snippets), VSCode, Coldfusion Builder configured for debugging, IIS, Microsoft Windows 10, Coldbox, Wirebox and our codebase. This is true for about 12 project environments as well. So our Questions for Coldfusion developers supporting Coldfusion Server 2018 and older. 01. Are you using Coldfusion Builder (not the VSCode extension)? a. Which version? 02. Do you use the Coldfusion Builder debugger? 03. If not using Coldfusion Builder, What is primary development tool? 04. Where does your code reside on your development machine? a. Under c:\CFServerLocation\cfusion\wwwroot\workspace b. Somewhere separate from server install files 05. What internet server does your code use? a. Coldfusion Built-in Apache Server b. Microsoft IIS and Tomcat ISAPI c. Other Questions for Coldfusion developers supporting Coldfusion Server 2021 and newer. 06. What development environment are you using? a. Visual Studio Code and Adobe Coldfusion Builder Extension for VSCode b. Visual Studio Code and Other Coldfusion Extensions (please list) b. Eclipse and Coldfusion plugin or list other plugins. c. Notepad++ (please list plugins you use for coldfusion) d. Other (please list) 07. If you are using the Adobe Coldfusion Builder Extension for VSCode, do you have your development environment staged to mimick or closely approximate your production environment. If yes, what webserver are you using? a. Microsoft IIS and tomcat ISAPI? b. Built-in Coldfusion webserver? c. Other (please list) 08. If you are using the Adobe Coldfusion Builder Extension for VSCode, are you successfully using the debugging features? If so, where is your workspace? a. Under c:\CFServerLocation\cfusion\wwwroot\workspace b. Somewhere separate from server install files General Questions 09. Do you have coldfusion server installed locally on your development machine? 10. Do you have more than one web application being served by Coldfusion on your dev machine? a. How many additional applications? 11. Do you use the host file locally to approximate your server DNS environment? Ok, so the primary reason for getting some of these questions answered is that we're moving our codebase from CF2016 to CF2023. Since there is no Coldfusion Builder standalone, we'd like to get our basic issues resolved with the VSCode Extension. We also already use the following VSCode extensions and would like to still be able to utilize some functionality between them and the Adobe CF Builder Ext.: Name: Alpine.js IntelliSense Id: adrianwilczynski.alpine-js-intellisense Name: Alpine.js Syntax Highlight Id: sperovita.alpinejs-syntax-highlight Name: CFML Id: KamasamaK.vscode-cfml Name: CommandBox Id: ortus-solutions.vscode-commandbox Name: Docker Id: ms-azuretools.vscode-docker Name: Live Sass Compiler Id: glenn2223.live-sass Name: Live Server Id: ritwickdey.LiveServer That being said, the rockband.7z file will contain everything necessary to give a full description of what we use to stage a developers Coldfusion environment. Hopefully it's enough to get everyone on the same page. We try to separate our workspace and our server space on our development machines same as our production machines to increase security and make the codebase more portable. Any questions or comments, please reply hear to benefit all of us.

@Charvi @Vikram Kumar

I'll answer for my setup, but Mark may want to cover his ears for this... 01 - no, never did like it; 02 - no, I never liked step debuggers; 03 - VS Code; 04 - (b) always outside of the server install and almost no files under the webroot (just Application.cfc and index.cfm); 05 - not sure what you mean by "Coldfusion Built-in Apache Server" -- what's built-in these days is Adobe's version of Tomcat (not a stock Tomcat, as I understand it) -- we currently use Nginx with plain http proxy to Undertow, because we use CommandBox to run our CFML server, and prior to that it was Apache (web server) with a plain http proxy to stock Tomcat running CFML as a WAR. 06 - (b) VS Code with CFML Editor; 07 - n/a; 08 - n/a. 09 - locally, yes, powered by CommandBox (same as QA and production); 10 - not any more as we only have one CFML app left, previously we ran each app separately on dev/QA/production with CommandBox, and prior to that it was multiple apps on stock Tomcat. 11 - yes, we have all our app domains in the local

hosts

files (with

dv

prefixes -- our staging sites use domains with

st

prefixes).

Thanks for the replies @seancorfield, and yes, that was supposed to be Coyote Tomcat not Apache for the built-in. Keep me honest! From what I'm seeing on the most of the forums, the lack of discussion on debugging does not bode well for line debuggers. Coming from the Visual Studio side with C# and VB.Net I've been spoiled by Microsoft, especially with being able to attach a remote debugger to a single process on a webserver. We're a ways away from that it appears.

Back when I did C++, you pretty much had to use a step debugger, but since I switched to Java in the late 90s I've never found them very useful (and the CFBuilder one was pretty flaky at best).

01. No, seemed like a pain to set up. 02. No. 03. VSCode. Before that, Sublime Text 3. 04. Wherever I pull it down to. 05. B for prod. 06. VSCode. CFML-Related Extensions: CFML Editor; CFML Editor Linter. 07. N/A. 08. N/A. 09. Yes, via CommandBox. 10. Yes, each set up with CommandBox. A bunch, it varies. 11. No.

06. IntelliJ IDEA w/ CFML Plugin 07. Everything I build is in Docker containers. This matches my deployed images in Dev/Test/Prod. I use Traefik locally to proxy HTTP requests. In production I use a combination of Traefik, K8 Proxy or the cloud-provided proxy service (lightsail, EC2 ELB) 08. No. BUT I am using the IntelliJ IDEA debugger coupled with FusionReactor. All of my code is GIT controlled and each project/customer has their own Docker image container that I work with. 09. Kinda. I have a docker image for each customer/project. 10. Yes? I manage at least 25 different projects/customers and each has their own docker image and container. I don't run more than one at a time. 11. Nope. This is managed through Traefik and my Docker setup.

Thanks @bendur and @quetwo, appreciate the difficulties in maintaining dev, test and prod environments. We are using docker containers locally for developers to be able to spin up a coldfusion server quickly with their database of choice. Two more questions for you both pertaining to your testing environments, any testing frameworks in place, any automated testing in use?

You didn't ask me but TestBox and fully-automated testing (and deployment).

Thanks @seancorfield! I did ask you separately, but it appears it never made it out of my drafts!

We have our own testing suite that we manage that is in-house. We hadn't really found one off the shelf that tests both endpoints (REST fuzzing), CFML output and CFC functions in one shot.