I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).
Related
I'm developing a C++ application that dynamically link against Qt, boost and Assimp. I compiled it in Release mode with /MD and it works fine on my computer. However, if I try to run it on another machine I get the 0xc000007b error (The application was unable to start correctly). I use Windows 8.1 on both machines but Qt5.3 and VisualStudio2013 are only installed on the 1st machine.
I built boost with
bootstrap.bat
b2 variant=release
I then used Cmake GUI to configure/generate a solution for Assimp that I later built using Visual Studio 2013.
Qt (32-bit version) was installed via the online installer. So everything (including my application) is built with a target 32-bit.
The folder that I copy to the other machine includes:
MyApp.exe
platform/
accessible/
assimp.dll
icudt52.dll
icuint52.dll
icuuc52.dll
kernel32.dll
opengl32.dll
libEGL.dll (cannot be found in Qt/5.3/msvc2012_opengl/)
libGLESv2.dll (same)
msvcp1XX.dll
msvcr1XX.dll
The Qt libs that I need (Core, GUI, Widgets, OpenGL)
If I copy these .dll/folders from Qt/5.3/msvc2012_opengl/, the app requires msvcp110.dll to start. If I add it and run it, I get the 0xc000007b error. But why msvcp110.dll instead of msvcp120.dll???
And if I copy the files from Qt/tools/QtCreator the app actually needs msvcp120.dll to run. But when it runs, it crashes at the beginning with:
QEGLplatformContext::init: eglError: 3005, this: 0x2e806b0
Which I guess is normal as you're not supposed to copy them from this location.
Does anyone know what I am doing wrong?
PS: I also ran vcredist_x86.exe on the machine without VS2013 before running my app. It installed successfully but nothing changed.
Thanks for your time and your help!
I created a simple application in VB.net in Visual Studio 2013.
It's not a website or a web app, it's just a simple Calculator, I think I created it as a Windows Forms Application.
When I build the application in release mode, it builds and runs properly.
It puts the executable it built in: Documents\Visual Studio 2013\Projects\DataCalculator\DataCalculator\bin\Release
I can just send that executable alone to someone and the program works fine. So what is the purpose of all the other files?
Furthermore, there is a Publish button in the Build menu of VS2013. What does publishing the program do that the the release doesn't?
Also, when I click the publish button it asks me how the user will install the application. What if I don't want them to install it, I just want it to run from a simple click of the executable. So what is the purpose of publishing?
If by "all the other files" you mean .application, .manifest, .pdb, etc., they all have uses in various contexts. If your calculator is stand-alone, then it will only require the .NET Framework version you used to create it installed and the .exe itself.
I have used the Publish feature a few times - at a previous company - it's useful for 'transparent updates' to users. For example, the tools I created were published to a shared drive on the server along with the associated "other files". The users then installed the tool from the shared drive by clicking on the setup/install version, which creates a shortcut on their start menu/desktop/wherever. The beauty of this particular method, is that you can configure the application to automatically update when it is run; so I continuously improved the tools and every time a user ran one, it copied the newer exe to their PC and ran that, without any further updates/reinstalls from their perspective.
It worked quite well for small engineering tools, but I'm sure with larger/more complex applications with databases and backward-compatibility to worry about, it could cause headaches in many situations.
Release will only create an .EXE Application file which is executable in supported platforms, but database must be separately copied . where as publish will create a setup file along with database and the sub folders inside the project folder. It helps you to install your application in any computer which meets the requirements.
Click to refer Advantages and procedure for publish http://msdn.microsoft.com/en-us/library/vstudio/ms233806(v=vs.100).aspx
Greeting,
I'm having difficulty deploying my Smart Device Project into the SD Card of my MC2180. My application uses Microsoft SQL Server Compact Edition v3.5, and it need to be deploy on a WinCE 6.0 device (MC2180).
Now the problem is :
1) If I do a normal deploy to my device, I can set it deploy the "Application" in my SD Card, BUT the SQL still install in my Program Files, by any chance if the device got a reset my "Application" won't work anymore because SQL is not there.
2) I can create a CAB File, BUT I don't know how to include my SQL installer.
What I want is to make a CAB that can install everything nicely, OR, make the program portable :)
Please advice what can I do :) I'm using Visual Studio 2008.
Regards,
Milo
You may try to extract and repackage files in the SQL compact cab, but this may be clumsy and still have some issues if those file must be placed in the Windows folder to be found from the loader and your device configuration does not support a folder for executables on the SD card. Usually the simplest solution is to install the cab file by launching wceload every time you app starts. You can suppress the UI using the /noui command line switch. Obviously you may add a check that verifies if the files are already in place (to avoid multiple installs that will be a time waste) and you'll also need to load classes/forms etc. that reference the SQLCE modules only after you've finished the installation.
I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
Is it possible to create a VB.Net application which users can just run without installing it first.
If not, is it possible in another .Net language.
If not, how IS it possible :)
PS: The application only has to run under Windows (>= XP).
If they have the .NET Framework installed (the version of it that you developed it), they only need the .exe. You can find the .exe file in the bin directory of your projects folder in your Visual Studio workspace.
If they do not have the framework installed, you'll need to produce an installation for them. It's extremely easy with Visual Studio by just creating a setup project in the same solution as your code.
As long as the user has the .net runtime installed, and your exe has any needed resources in the same folder (dll's, images, ect) theres no problem with that.
If you mean without installing the .net framework though, that won't be possible.
just build the program, and go into the (assuming the project name is app1) app1/app1/bin/debug/ dir. there should be a file there called app1.exe. this file is the compiled .exe from you project. any other computer will be able to run this without doing any installation (provided they have the .NET framework installed (it comes standard on any computer with an os > WinXP))
EDIT: If you were building with debug configuration, it would be app1/app1/bin/debug/, but if you were building with release configuration (which would probably be a better idea if you are distributing) the path would be app1/app1/bin/release/
If you mean running it without the .NET Framework, it used to be possible, but apparently the company's website is no longer in English so I have no idea what's happened to it.
EDIT: If you were building with debug configuration, it would be
app1/app1/bin/debug/, but if you were building with release
configuration (which would probably be a better idea if you are
distributing) the path would be app1/app1/bin/release/
I am developer and have no administration rights to live(production) network.
I had to find away to deploy an app without installation... and my app is self updating this cause other problems too....
The production network Computer check/monitors the file versions etc, so updating in the program files can not be done, where a MSI has been used for deployment.
Using this above I am able to copy and Run the App from the User Profile (where the user has full rights).
lets understand how program runs-
an .exe needs some function which are not inside the .exe, such as , for example substring() function. these predefined function resides in some .dll libraries.
when .exe is executed by user, .exe first finds the .dll and then the function inside that particular .dll.
.exe first looks within the current folder for that .dll
if not found then it searches that in PATHs. (PATH is Environment variable which value is a list of folders such as System32 etc.)
an .exe usually needs only 3 things - .exe itself, .dll which predefined function it is using, and some ActiveX controls(.ocx). apart from these 3, .exe only uses resources (such as icons etc).
lets focus on these 3(.exe, .dll, .ocx)
first you need to check what .dlls your .exe is using. you can easiely do this by using a dependency walker.
then make sure all these .dlls (that dependency walker is showing,or in other words- all these dlls whose functions your .exe needs) are either in current folder(in which your .exe resides) or in the PATHs.
if this step is done then your .exe has high chances to run whithout "installing".
the only problem is that some .dll and all of .ocx, needs to be registered first(means they have to have some kind of registry entry). they are not ready to use just by copying and pasting in current folder or PATHs.
but you can register these .dlls and .ocx's by using regsvr32 (with command line).
after that your .exe should not face any problem to run successfully.
hope you got the main concept.