Unity 2017.2 - 'UnityPlayer.dll' being created after build (22MB)

When I build my project with Unity 2017.2 it creates a 22MB 'UnityPlayer.dll' file on my desktop that is required to launch the game. If I delete the .dll and I try to launch the game I get a system error telling me UnityPlayer.dll is missing from my computer.

This is something I obviously do not want happening when I ship my game. What is causing this?

Thanks,
Corey

 

Bump.

 

I assume this happens on a Windows PC?

If you build your game via "File > Build & Run" for example, Unity copies several files to the selected output directory. In your case, I assume you selected the "Desktop" as output directory at some point.

A Windows Standalone build outputs various files and folders to the selected output directory, for example:

• YourGame.exe
• YourGame_Data (this is a directory)
• UnityPlayer.dll

Deleting any of those files will cause issues.

 

It is a Windows PC yes. It wasn't creating a .dll file before though. Does this mean when I ship my game I need to ship it with this .dll? Just having my player require 3 spaces on their Desktop for a game seems a bit inconvenient.

 

I bump this issue, didn't happen with Unity 1.1p4

 

If it works in 2017.1.1p4, but does not in a later release, then you most likely found a regression. In this case, I recommend to submit a bug-report following the advice in this document.

Using the bug-reporter seems to be an important step, because it makes sure the report is in Unity Technologies bug-tracking pipeline and has to be processed at some point. Using the forum is often used to add to a little more attention to a bug-report, but does not replace submitting the bug-report.

It's from advantage to attach a project to the bug-report that UT can use to reproduce the issue and test their fix against. The easier an issue can be reproduced by QA, the more likely it is to get forwarded to a developer, who might or might not work on a bug-fix for that at some point.

After you submitted the bug-report, you receive a confirmation email with a Case number. UT often asks us to post the Case number in the forum thread, which allows them to find that bug-report if they look at your post.

Following these steps will increase the chance that UT is looking at your issue tremendously.

 

Maybe i'm wrong (and correct me if i am) but the problem with the bug reporter is that you have to upload your project, or create a test project that reproduces the issue.

The thing is, I have time to check forums about the issue, but maybe not doing QA and test repo in my working time (especially for an obvious issue like this, seen by anyone that makes a build), plus my project isn't very suitable for an upload and test.

More of that : I saw after my bump in the release note something about this dll, now separate from others dlls. So I don't really know if it's a bug or a legit behaviour anymore, since there's no communication about that (or I didn't find it).

But i'm legit interested by submit bug without upload anything, just discribing the bug. Is that possible ?

Thanks a lot !

 

The thing is, do not assume that UT is going to fix a bug if you do not submit a bug-report.

Posting in the forum isn't usually a place where UT is picking up bugs. Some UT employees actually do, but I believe that's just because they care for their work more than others. The official way is to use the Unity Bug Reporter, which also allows you to track the issue.

I believe it doesn't matter what project you attach to the bug-report, as long as they can use it to reproduce the issue. It could be even an empty project if it can be used to reproduce the issue.

It definitely costs more time than writing in the forum, but a forum post on the other hand most likely won't cause UT to provide a fix.

The easier an issue can be reproduced by QA, the more likely it is to get forwarded to a developer. Attaching a project to the bug-reports rates your report as higher quality than a report without project, thus your chances that someone is actually looking at your report increases.

See here for a blog-post how to improve the chance that UT is looking at your report:
https://blogs.unity3d.com/2013/10/28/bug-reports-incidents-and-some-bashing/

 

Oh cool ! I tried in the past but I remember I couldn't. Nice you allowed it now. Thanks !

 

a question @Schubkraft : at the moment with unity 2017.1 I have 2 exe in the same folder, with different name and everything works fine.. but if I upgrade to unity 2017.2 I suppose that something goes wrong, 'cause the dll name is the same and not depends by the project name or the .exe name..

how can I do?

thanks

 

thanks @Schubkraft .. I wish only undestand the new 'dll' that appears on build and how I need to manage in my project..
each build the dll changes or not?

 

that's good, so if I have 2 exe in the same folder, they should share the same UnityEngine.dll... right?

 

fantastic news!
thanks @Schubkraft

 

The only bug is the Access Denied breaking the build if UnityPlayer.dll is locked due to another app in the same folder already running!
This is making incremental build of a gameserver and client residing into same folder with external data files major PITA since 2017.2 (I will file a bug for this later)

 

Ugh, this is a huge pain for us. We also keep multiple Unity apps in the same installation folder, and now we can't.

 

no, that should be fine, a single dll and more exe.. less space

 

It doesn't work for us, because we need the apps to sometimes be built with two different versions of Unity, and we update and patch them independently.

 

Is there any way to get this moved into the _Data folder or somehow or other support two Unity executables in the same directory with different Unity versions?

 

I don't understand why a project which only contains on screen text after I built it is somehow 50mb.
I have my game.exe and a data folder and now we have this new Unity.dll?

How can I get rid of this unnecessary 22mb dll file like before when it was just the data and game.exe folders.

 

So they won't work if I for example have a 2017.2 exe sharing folder with an exe from a future version of Unity? If so, that's a big issue.

The executable I produce are used and handled by non nerd people. Having to ensure the Data file is with it's exe brother is already an issue. That dll file will become a serious reliability hazard.

How about an "exe folder" so we can have a single file?

 

+1 to the comment above. Screw even showing a data folder, just have it all loaded into 1 Exe file and that's all we need to worry about. Simple is better.

 

Anything new about unityplayer.dll?

I haven't installed 2017.3 yet but didn't find anything about unityplayer.dll. :-/ I already have issues with this "feature" and seriously needs it to be optional. I can't afford a hotline for all the people who will inevitably forget it and blame me for the application not working.

 

Hi Schubkraft.

Could you answer my last question? Unityplayer.dll is causing trouble and I have to solve it these next days.

Thanks

 

Hi.

Did you find a solution to move it to the Data folder? I have the same situation and have to find a solution fast. :-/

 

So why did you guys made that change if you don't have the resources to handle it?

This is not a beta test, people are making a living out of your engine and can't risk being discredited because you don't finish your work. Please put that dll file back where it came from.

Thanks

 

but what's exactly your issue about `UnityPlayer.dll`?

 

I'make you an example. You want a game. And you need to update it or patches and you use a launcher. So you make 2 unity projects. "The Updater" and the "YourGame". Both in the same folder. The Updater now can't update because there is a new file outside _Data folder

Another example "The Updater.exe" made in Unity2017.1 updates "MyGame" made in Unity2017.3. But is not possible because they are in the same folder and shares the same .dll

Another example: Game A is calling Game B and both are in the same folder. Game A is open so Game B can't open because is sharing the same .dll

@Schubkraft is this .dll outside the _Data folder for a good reason or is just branding? because there is no good reason to be outside the _Data folder "This folder contains all the data needed to run your project.". And is creating a lot of shipping problems. Also in this way, I'm expecting from Unity that there will be more .dll around my .exe in the future.

 

I have exactly the same case AlanMattano mentions, with a patch client made in Unity for our game. The patch client and game .exe are in the same folder. My only solution for now has been to keep building our patch client in Unity 5.6 instead of what we build our game with, 2017.2. Otherwise, I would have many days of work to try and restructure the way our game is setup to work around this. (Many days because our game is on 3 platforms, i'd have to make changes that work for all 3, make sure the change is backwards compatible (so old versions can still update), make new installers for all platforms, etc, etc.)

 

Why don't you store the updater and game in separate folders? Sounds like this would solve all issues you described, which basically boil down to sharing the same dll files.

 

We have that same app/updater layout in same folder - I guess it is only because we have not updated the updater for ages that we do not have such an issue (!) but agree the change could be problematic if you have such a setup. An option to combine dll & exe would be best of both.
But is it not the case that a new dll could work just fine with a slightly older exe unless it has dropped some functions?

 

You can not move it because you need to update al the icon path in windows start and icons in the desktop, and other connections that the player has made to the game or plug-ins. And also the patcher is not able to handle the binary difference. In size, that particular update will be like shipping a new game. And at that point is better to uninstall the game and install it in the new structure folder. At that point, the player will ask us "way there is an updater that does not work? Or worse, why are you including a launcher updater and later ask me to download all the game.

So you need an updater that updates itself. Or you need to give the player a new updater in my case made in Unity5 pro so there is no repetitive Unity intros and no .dll so is clean in the folder. In the case, you have a launcher and a game that update them salve is possible but the player needs to configure one more time the firewall and the antivirus, the path of the icon. The shortcut is a new installer.

At this point, the only way to move the game is to uninstall it and reinstall it.

 

You can edit your exe file in HEX editor.
Just find UnityPlayer.dll find replace it for something like game_Data/e.dll
Just make sure not to change symbols count its 11 in our case.
Thane move the dll in the Data folder and rename it to e.dll
Not a good way but seems to work.

 

I agree in general, that this dll either be optional or moved to the data folder. For small projects, an extra 22MB seems excessive, especially given previous versions didn't require any additional dll files.

Is there a live bug report anywhere, that we can upvote?

 

at least the choice should be optional, for example my project has 2 exe created by unity in the same project, and they share the same dll and is a good thing, I've to send to the people 22mb less than before and when I do changes the dll remains the same

 

We deliver ArchViz-Executables to clients.
Clients are very often not very familiar with data in genaral.
So this is definitively a case where less files are better.

So please: Make the seperate dll optional.

(I even would suggest to optionally pack the datafolder into the executable.
@SilverStorm : Right, the simpler the better.)

 

I've been trying to install SCP containment for a while now and whenever I try to open it from my desktop it says "cannot run file unityplayer.ddl could not be found" can anyone help?

 

Agree that at the very least this .dll should be able to be inside the data folder, as an option. It was already risky having external users have to remember to copy the _Data folder as well. Now there is a UnityPlayer.dll, Mono folder, Unity crash reporter as well.

For our use case, one file is preferred. It does not matter if it's bigger. It is less risky and easier to deal with.

 

I don't think Unity intended the raw output of the build process to be directly distributed to customers, they probably expected people to use third party software to create installers. I certainly wouldn't be distributing raw zip files to non tech savvy customers in normal circumstances.

Have you considered a self-extracting archive? You can use 7Zip to make nice and tidy exe's that will extract their contents to a temp folder and execute a specified exe. That should get you a self-contained exe you can distribute to others.

 

Wow this is so stupid. So Unity decided "you know what, let's make developers carry a silly dll file, and if they don't their games will crash". Talking about backwards developing.

 

I have "Common Tools for Visual C++ 2017", "Windows support for C++" and "Windows 10 SDK" installed.

You can show an example - HOW to do it?

In docs doesn't say anything, except one mention (quote):