I am creating an augmented reality desktop application using Unity and ARToolkit. For test purposes I have created a single scene application to test the working of the ARToolkit, it runs perfectly in unity editor that is, the webcam and all is working correctly in unity editor. After building the application when I am opening the .exe file, it is not opening the webcam and is giving ARWrapper.dll dllnotfoundexception. HOw should I resolve it and how do I enable my laptop webcam in the .exe application file ??? Attached image is showing the problem at hand..
have a look at the documentation here:
http://artoolkit.org/documentation/doku.php?id=6_Unity:unity_on_windows
Looks like the ARWrapper.dll needs to be in the same directory as your app.
Best
[edit]
Excerpt from the documentation I mention above:
"
In spite of the ARWrapper.dll clearly being in the referred to folder, the Unity Editor may not be able to find a required dependent DLL (i.e. a DLL on which the ARWrapper DLL depends). Confusingly, the dependent DLLs must be present in same folder as the .exe file of the host application (the Unity Editor, in this case), which is typically C:\Program Files (x86)\Unity\Editor. The required DLLs are normally (at least since ARToolKit for Unity v2.0.3) installed by the ARToolKit for Unity installer, but if you are having difficulty, you can double check. Check that the following are present in that folder:
ARvideo.dll
pthreadVC2.dll
opencvcore246.dll - opencvflann246.dll
DSVL.dll
"
Related
I'm struggling to find any method that works with current Unity.
This for a conventional Windows build (not a Windows Universal via VS).
So, there's the separate data, dll, etc files of a build: how to create a civilian-usable "single exe" for Windows, with current Unity??
As said afaik this was actually always the case.
See e.g. Windows standalone Player build binaries to see a list of resulting output of a build. It exists back until version 2017.2.
So the short answer is:
It is how it is. You will always get multiple files and the data folder as output.
What you can do however is using a pack tool which simply packs all your folder content into one single exe file.
One example is Appacker
=>
BUT unfortunately there is one known issue: Windows Defender recognizes it and every exe created with it as malware. The reason for that is actually mentioned by the author in the link
Spoiler: A self-extracting .exe file? Windows Defender hates that trick!
So either with this tool or any similar one there is no real way around that except you need to trust the tool and your users need to trust you ^^
(The icon is also only used for the process window, not for the exe file itself ^^)
The long and correct way would probably be to create an actual installer for your final app which is then allowed to extract all the files to a certain location.
So in the end the user anyway will again have an exe and according data and dll files e.g. in the Programs folder but get a registered shortcut to the Start Menu which is just how any other application on Windows usually works like.
Just to add to the answer.
In 2020 if it's a game you should just use Steam. Making auto-update way easier for your users.
https://partner.steamgames.com/doc/gettingstarted
My question is very simple and yet very complex.
I need to side load my application's .appx file to SurfacePro (Microsoft tablet with windows10) but I cannot side-load it because there's nothing to side-load...
I've created a simple unity project and switched the build to Universal Windows Platform (UWP)
I've made sure I have the latest IIL2CPP on my machine and all the needed libraries on my VisualStudio 2017
I build the unity project in a dedicated directory - the build resulted with success and the directory had a solution file = .sln file.
I double clicked the .sln file and opened it in VS 2017
In VS2017 I chose "Master", "X86" and "local Machine" (I then tried "device" and "remote machine" this gave errors) and build worked!
I then saw my application's "made with unity" logo and the scene
I close the application using Alt+F4
I want to re-open the application but I can't find the file! I understand this is a file that need to be side-loaded to my machine, similarly to .apk files which loaded and installed on android devices
I can't find the .appx file
I understand that I need to run the build each time I need to open the application, is that true?
I have no experience with the Unity side of this...
but to create the packages for a UWP application, you would right-click the Universal Windows project and choose Store-->Create App Packages.
When I run my Unity app in the editor, it is able to read my .dlls and other custom files the .dlls need and it works fine. However, when I make a build, it only includes the .dll files in the Plugins folder of the build and not the other custom files. Is there a way to force Unity to include the other files as well? I have tried putting them both in the Plugins and Resources folder before building and in both cases it only keeps the .dlls.
The custom files are .obf, but I don't think that's relevant
It is extremely relevant. Unity does not support all type of libraries.
Here are the supported library extensions:
For Windows, you can use .dll.
For Linux, .so is supported.
For Android, you can only use .aar, rar and .so.
For iOS, .a is used but you can also use the non compiled code such as ,.m,.mm,.c and .cpp.
There is no support for .obf. If you want to add it to your project so that you can load and execute it then you are out of luck.
If you just want to make Unity include it to your final project build so that you can read it then you can. This doesn't mean you can load and execute it.
First, rename the extension from ".obf" to ".bytes". Place it in the Resources folder and read it as TextAsset with the Resources.Load function. You can the access the data with TextAsset.bytes.
TextAsset dataAsset = (TextAsset)Resources.Load("YourObfName", typeof(TextAsset));
byte[] data = dataAsset.bytes;
Not sure how helpful just reading it is but this is here to show you how to include it to the build and read it but you can't execute it unless there is a C# API to do so and I don't think that any API of such kind exist.
I'm currently working on a project that will be buildt in webgl. It uses an asset that runs an .exe (cmd window) file to convert data that I need. But this does not work in webgl as it can't call the .exe file.
So now I'm searching for solutions. I tried to change paths and everything but nothing worked. Now my thought would be to make a second unity project that runs on a server and waits for a request. When the request gets sent out of the unity webgl project, the unity project on the server hears that request and runs the asset, after it finishes, it will send back the gameobject created. But I haven't tested it yet.
Would there be any other possible way?
Why do you want to download an *.exe file to get assets from a server?
Your issue sounds like you want to implement a normal gameclient with an unity gameserver that provides you with assets.
The good news is Unity implemented this one for you! :)
You can create an assetBundle and get it via network communication:
https://docs.unity3d.com/ScriptReference/AssetBundle.html
Steps would be:
set up a public reachable webserver ( for local testing you could use XAMPP )
place your package there (htdocs)
follow the instructions from link above.
I'm trying to build a LabVIEW plug and play instrument driver project for a device we sell. I followed the instructions to create a project, and it created the project in with the LabVIEW program:
C:\Program Files\National Instruments\LabVIEW 2011\instr.lib
I suppose I could connect that folder to source control and just do all the work there, but it feels weird to be working under Program Files. When I tried to move the project folder out into my regular workspace folder, it broke all the subpalette files (*.mnu). I could recreate them, but I'm afraid they wouldn't work for our customers when they install the driver from the LabVIEW web site.
Is it possible to move a driver project around, or does it have to stay in the default location? If one of our customers has installed LabVIEW in a different location (say on drive D:) will the driver menus not work for them?
I'm not in favour of user.lib for SCC'd items. using several LabVIEW versions at a time is a big problem.
Here is my routine:
Create the instrument library and save all code in a folder starting with an underscore ('_') (_foo)
Create an .mnu file in the parent folder of '_foo' Mylib.mnu, add the icons you need.
With OpenG package builder I create an installer routine that placed the the mnu file and the folder in instr.lib
After a restart of LabVIEW the instrument driver shows up in the instruments palette.
If you keep the code in the same relative position to the mnu file there is no problem with missing VIs.
Ton
Instrument drivers are always located in the 'instr.lib' folder in the current LabVIEW version folder. There is an environmental path set up in LabVIEW for this intrument driver folder so it will always point to the correct drive for the installation of LabVIEW used.
You should keep the folder in the location used by the wizard to ensure that when distributed to your customers the sub palette menus point to the correct location and all the VIs link correctly.
I use source control for user.lib which is in a similar location and have no problems.