When I go to build a Windows project, it no longer allows me to name the executable, it just allows me to select a folder and then names it after the folder.
If this is a bug I will file a report, if not, it would be nice to be able to select if we want to name it or not like we have been doing for a decade now for Windows apps.
filename is a pro only feature
j/k
it works for me in b8 so it must be a bug in b9, file it
in general: file anything that looks off
Itâs not a bug - the beta 9 changelog lists it as a change: Unity Editor Beta Releases
Windows: The Build Player location selection dialog now asks for a folder rather than a file name when building Windows standalone player. The BuildPipeline.BuildPlayer API is not affected by this change.
Thanks mustâve missed that one, hope they will make it optional, Iâd rather have more control than less over things.
I though Unity devs were done with these types of changes that donât bring anything to us. How do we test builds settings side by side?
I imagine itâs to unify how builds for other platforms work, where you often specify the build directory only. Now everything seems to work the same, no matter whether you build for Windows, iOS, Andoid, Xbox, whatever.
Now itâs always a directory, rather than sometimes a directory or sometimes a file path. It makes it easier on the custom build scripting end. I certainly like the change, UNLESS this change only affects the UI and not the build API as well 
so, just manually rename after every build. that sucks.
[URL=âhttp://[URL=âhttp://â[URLââ]https://docs.unity3d.com/ScriptReference/Build.IPostprocessBuild.OnPostprocessBuild.html[/URL]
OnPostprocessBuild to the rescue!
They really should now let us put the preferred exe name in the player settings. Thereâs no reason why we should type that manually anyway.
Seriously this is VERY annoying. This MUST be set as an option.
I didnât test it yet, but I would assume the product name in the player settings is used as .exe file name? That would conform how output is named when targeting other platforms than standalone.
Just uses the folder name, have to rename if you want it something special.
I confirm, Iâve used Build-folder in past, now I get Build.exe 
My temp workaround is to put additional folder with project name under Build folder now but it seems like extra step, for example /Build//
Quoting to remind. Not sure why a perfectly correct solution is ignored in favour of hacks etc.
So that when they finally hire a real build engineer, he/she has some job security?
Sorry, donât understand what you are saying.
Apologies. Itâs sarcasm. My real job used to be builds, and unraveling hacks like those, put in place by whatever dev used to be stuck solving release issues I guess, was a big part of any new job I had. Most folks ignore features until they see them used. If youâve never had to run automated builds, the pre and post hooks probably never were any use to you.
A real build of my project requires 3-4 executables for standalone platforms because some of them are servers. This change will require me to alter my build code a little as a result, but itâs a reasonable change, and had I set up my build âproperlyâ in the first place, there would be no change needed at all. Android and webgl builds already required me to handle them as folders. To re-state something from a comment above, making each platform consistent reduces overhead on the folks doing the builds.
Yeah I wanted to remind people that there are hooks. Iâve been using hooks for build for, well whenever I could I guess. Nobody likes doing builds. In fact some of the most fiddly processes Iâve endured were from Apple back in 2009. It really didnât have any sense of sanity to it.
What I didnât like was being the last person to touch things before either users or QA gets it. Means that no matter who effs up, itâs your fault. Other than that, builds can be a fun challenge.
BTW, one thing I get to explore with Unity that I never had much of before was the ability to script a build pipeline using the editor itself. So I actually donât use those hooks. Iâm completely free to define what my builds do in editor script, then call them either from the menu or batch/command line.
I made this change and it was intentional. This is consistent with how most Unity platforms work: we want to move to world where platforms behave consistently. This change was also made because nowadays standalone player builds donât produce 2 files like they used to in the past. You now have UnityCrashHandler64.exe, WinPixEventRuntime.dll, UnityPlayer.dll, and if youâre using IL2CPP scripting backend - GameAssembly.dll. We also moved Mono folder to be next to the executable to enable truly side-by-side 32-bit and 64-bit builds. With these files, you already couldnât build 2 builds into the same folder because all those files need to match for a build.
Lastly, we have a new feature coming in 2018.2 (just landed to alpha this weekend) that allows you to generate a visual studio project instead of the final executable for Windows Standalone builds so that attaching debugger and modifying final executable is easier. That also requires you to build to a folder (I canât even imagine how else that would work).
In the past, you just named .exe differently. Now you can name the folder differently. Not much has changed.
Unfortunately it only affects the UI for now. I tried changing the API but it broke just too many things. There are tons of asset store plugins that depend on the path passed to BuildPipeline.BuildPlayer being an .exe, and I couldnât justify such a breaking change right now.
No, just name the folder with the name you want.
Right now it uses the folder name - that was the simplest solution that preserved the old behaviour of specifying .exe file name in build dialog. We can consider changing it to use product name instead.