Deploying a Windows 8 Metro application that uses SQLite - sql

Background
We're using System Center 2012 to deploy a Windows 8 Metro-style application to Samsung slates in the field running Windows 8 Enterprise x64. The slates are joined to the domain and have a persistent DirectAccess connection back to it, allowing System Center to push applications and updates to the devices.
We have to deploy our application to potentially hundreds of devices in the field, which is why we went the System Center route. The code signing cert is installed on every device using Group Policy. To deploy the application, you simply provide the package output and specify the collection of devices to install it on. The app just shows up on the device in a few minutes.
The problem we're having is that when System Center deploys our application, the SQLite dependency is lost and none of our data access works.
About our project
Our application is a WinJS application that uses SQLite as a backend. However, all our data access code is in a C# WinMD project which the WinJS project references. We're using the sqlite-net library to talk to SQLite - we included the source for that in our C# project.
In Visual Studio, we installed the SQLite for Windows Runtime extension as described in Tim Heuer's article. The Metro application references this.
Testing using other deployment methods
SQLite data access from the application works fine when you debug or run it locally - in both Debug/Release and x86/x64.
The app packaging process provides a PowerShell script that you can use to install the application and a developer license if necessary. When installing our app using the PowerShell script, SQLite data access also works fine. Verified this by packaging and installing both Debug/Release and x86/x64 versions of the app.
Troubleshooting
When the application first tries to use SQLite, we see an exception about it not being able to find the sqlite3.dll.
We've tried/verified the following:
Confirm that we're deploying a Release/x64 build
Examine the appx in WinRAR and verify that it contains the sqlite3.dll
Reference the "SQLite for Windows Runtime" extension from the C# project instead of the WinJS project
Also reference the C++ runtime, this caused System Center to fail when deploying the app. Don't know why yet, but looking into it.
UPDATE
The issue is that System Center is having trouble deploying the Visual C++ Runtime Library dependency that the SQLite library needs. So unfortunately this isn't a programming question anymore. We're getting some help on this and I'll post the fix.

I wanted to post the details of a temporary fix that we're going with. We've also gotten closer to the root of the problem, so I wanted to provide those details as well.
Recap of Issue
When referencing the Visual C++ Runtime Package from our Metro project, System Center is unable to deploy the application to the devices because there is a problem deploying the proper version of the dependency for the appropriate architecture and build flavor.
Our development machines running Visual Studio 2012 (and packaging the project for deployment) are using a newer version of the Visual C++ Runtime (50727) than what is available in a fresh installation of Windows 8 (50712).
Worked with the System Center team and confirmed that this was a bug in the version we were using and has already been addressed in future builds. We're going to work on upgrading the environment but that will take a couple of weeks.
Workaround
I confirmed and tested the following workaround:
Remove the reference to the Microsoft Visual C++ Runtime Package from the Metro project
Install the x64 version of the Visual C++ Redistributable for Visual Studio 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=3
Deploy the application
Works like a charm because the correct version of the dependency is there already. Obviously not a long term solution if we choose to also target x86 and ARM, but will get us over this hump.

Related

How do I build an Adobe AIR application using Visual Studio Team Services

I have a client with an application that is written in MXML and ActionScript 3 and is deployed as a desktop app using Adobe AIR. The client would like me to implement automated builds and releases for this application and currently uses Visual Studio Team Services as their build and release management platform. My question is, what is the best way to use Visual Studio Team Services (VSTS) to build an Adobe AIR application?
I am familiar with the amxmlc tool for building AIR applications using the command line but this relies on Java and I cannot find any documentation on how to run a Java-based tool from within VSTS. Any assistance on this matter would be appreciated.
I understand that Adobe AIR is an older technology but for reasons that are beyond the scope of this question the client does not want to rewrite the application in newer technology at this time.
In addition, alternative build and deployment platforms are out of the question. I have experience doing something similar using Jenkins however the client would like to stick with VSTS.
Please let me know if you require any additional information to help answer my question. Thanks in advance.
You can setup a private build agent on a machine (can be on your local machine) that have requirement software installed (e.g. JDK, JRE). Deploy an agent on Windows
You can build the AIR application via amxmlc tool, so you can add Command Line task to call amxmlc tool to build your project.

Visual Studio online build failure for an empty universal app

I just created a new empty universal app (windows 10) and checked it in on my visual studio online project.
The configured build is constantly failing on following error...
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\WindowsXaml\v14.0\8.2\Microsoft.Windows.UI.Xaml.CSharp.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
I set build configurations to use VS2015 but without any luck.
I keep thinking there's a simple configuration I'm missing here... but can it also be that it's not yet supported?
The project itself is just the standard template from Visual Studio.
I'm having a similar issue running with MSBuild 8.2 target missing under VS2013 Update 5 under Windows 10 TH1. Except my target is Microsoft.Windows.UI.Xaml.Cpp.targets. So not necessarily an issue with Visual Studio but rather the substitution for $(TargetPlatformVersion) in the targets definition:
<Import Project="$(TargetPlatformVersion)\Microsoft.Windows.UI.Xaml.Cpp.targets" />
I'm building a project from Microsoft (https://github.com/Microsoft/winsdkfb), so I don't think this is your problem (meaning you've not done anything incorrect).
I know this isn't an answer, but I suspect we're caught in a gap in the Windows 10 SDK & Tools. Those aren't scheduled to be complete and available until 29 July even though VS2015 has RTM'd. I tried to track down something in the VS2015 release notes without luck.
Just inform the solution I found on this thread.
At the time of writing, it appeared that VSTO serves were not yet updated with
the Windows 10 SDK.
The only way back then to make it run was by creating your own Build VM (through Windows Azure) and link it to your VSTO builds.
I posted the thread and got the answer on the MSDN TFS forum.
I have not tried it right now, but since Windows 10 is officially released now, I guess it may work out of the box.
We now support building Universal Windows Platform (UWP) projects on the hosted build service.

Titanium Studio with Windows Phone Plugin: Titanium SDK does not support the Windows platform

I want to do Windows Phone development with Titanium Studio.
I followed https://wiki.appcelerator.org/display/guides2/Getting+Started+with+the+Windows+Phone+SDK#GettingStartedwiththeWindowsPhoneSDK-UsingStudio(Preview) in order to get the Windows plugin. After a required restart of the software, the Windows option apears in the Deployment Targets when creating a new project.
Unfortunately, for all Titanium SDK Versions I have installed, 3.5.1.GA, 3.5.0.GA, 3.4.0.GA, 3.3.0.GA, I am getting an error like "Titanium SDK v3.5.1.GA does not support the Windows platform".
So I basically cannot create projects for Windows Phone.
I am using Titanium Studio 3.4.1 and followed the installation tutorial, though I deleted the SDK path after setting it (it is the default path, setting a value caused an error message, also I left the publisher GUID and Windows Store Certificate empty, since I just want to develop and don't have publishing credentials yet).
How can I create an app that runs on Windows Phone, too?
Edit:
I add some images to show the problem better. In the last step, I don't have the possibility to create a Windows project in Titanium Studio.
2nd edit:
As per Eduard's answer, I skipped https://wiki.appcelerator.org/display/guides2/Getting+Started+with+the+Windows+Phone+SDK#GettingStartedwiththeWindowsPhoneSDK-WindowsPlatform(Preview) and had to do it. Now I got Titanium SDK 4.1.0.v2015... and I get the option.
Unfortunately, it still does not work.
https://jira.appcelerator.org/browse/TISTUD-7171
So I also need to update Titanium Studio.
Well, I guess mobile development has to be buggy and cumbersome, at least that is my experience so far with various (cross-platform) products.
Try opening the solution generated in Visual Studio to attempt packaging the .sln to .appxupload to upload it to the Windows Store. Hopefully that will serve as work around until Titanium has full support for Windows (very likely 4.0.0 or 4.1.0 Titanium SDKs).

Visual Basic executable running in native mode, but not when starting from debugger

I have some big problems with my new environment and I think related to managed vs native code.
After my harddrive crashed I installed Visual Studio 2010 on a Windows 8 (which is new to me) and used backups of my Visual Basic .NET code files.
My issue is that the standalone debug executable crashes (with error code 0xc0000409) without me being able to see my source code ('No native symbols in symbol file'). It turns out it is running in native mode (Process: [140] myApp.exe: Native), which I did not think Visual Basic ever did.
When debugging from the GUI I have symbols and, to my surprise, it finds two MyApp.exe in the modules list, one native and one managed.
Some more details, I use ODBC, build for x86, and use .NET 4 client profile. As my project settings are similar or identical with my pre-crash setup I think the configuration problem is in my environment/OS, but I cannot find it after days of searching.
Can I make my standalone executable file execute in managed mode so I can debug it with symbols when it crashes? I have been able to do this for years with my old setup.
Any tips or hints would be very much appreciated.

PowerBuilder compatibility on Windows 7

I'm having problems migrating a PowerBuilder application from XP to Windows 7.
We've built the application in PowerBuilder on Windows XP, and when we attempt to install components in to component services on Windows 7 machines, we get compatibility errors. Everything works great on Windows XP. But I think because the DLL's on 7 are so different, it's having problems.
If the program was built using a PowerBuilder IDE in a Windows 7 environment, would that possibly fix the problem?
The application is divided into
- a server component running on Server 2003
- a client component which installs sucessfully on Win7
- proxy components that are generated into an MSI when the server components are installed.
The problem is only the proxy. The MSI doesn't want to work on Windows 7.
Without the proxy installed on the client desktops, the client can't communicate with the server.
When I run the MSI in compatibility mode on Windows 7, I get some details of the error. Here they are
Program Compatibility Issues found Incompatible Application Fix
application CCS_Proxy_XP_Exports
Issues found Incompatible Application CCS_Proxy_XP_Exports is
incompatible.
Fix application CCS_Proxy_XP_Exports Provides steps to fix the
incompatible application. CompatMode CompatMode UserVerifySolution
User Verification of Solution Verify_NO
Detection details Collection information Computer Name: ##########
Windows Version: 6.1 Architecture: amd64 Time: Wednesday, November
14, 2012 11:56:36 AM
Publisher details Program Compatibility Make older programs run in
this version of Windows. Package Version: 1.5 Publisher: Microsoft
Windows
Program Compatibility Make older programs run in this version of
Windows. Package Version: 1.0 Publisher: Microsoft Corporation
If I view more details on the event log, I get the following
“Product: Client Communications (Application Proxy) -- Error 1928.
Error registering COM+ Application. Contact your support personnel
for more information.”
General idea
Actually dll on the win7 platform are not different from previous ones. There can be differences related to the multiple and different C runtimes that live now in the WinSxS dll-hell directories but this should not impact powerbuilder (as I can say from my 11.5 classic release experience).
I suspect that you might have some problems related to the UAC and or ACL management. I recently upgraded some legacy PB applications by adding compatibility to the Vista / Win7 specifications.
In short : the application must run without needing administrative privileges, and must not try to modify data in privileged places like c:\ or c:\windows.
Thus everything must no more be installed in program files directory. The application binaries can be deployed in program files but if the application need to create / modify some files they must be deployed in a ProgramData subdirectory for user-shared datad and / or in the local user data files for the private data. The application has to be modified to create or find the files in the correct directories. If you do not comply to the standard, the file virtualization mechanism can hide a lack of rights and can simulate the files in a VirtualStore directory in the user local data but is just a workaround and it provides some other problems.
Com+ error
Given you error messages, if the proxy is also a PB application, given the fact that PB only produce 32bits binaries and that your system is a 64bits one, maybe that the tips to register a 32b COM+ onto a Win2008 could help you?
Thought, your proxy exe/dll file does not have manifest or manifest does not contains compatibility section. Try to add compatibility info to manifest.