I'm not sure whether this is intended behaviour, but is it normal for XCode (7.2) to create a separate executable on a physical device for a UITesting target, despite both targets having the same bundle identifier?
The new created target by Xcode for UI testing should have another bundle identifier like com.apple.test.<ui_testing_target_name>-Runner
Related
I am new to windows phone 8.1 developping and focus on library dev.
In the wp 8.0 era,I know if I want to create a Image instance.
I just write
amapLogo.Source = new BitmapImage(new Uri("/Com.AMap.Api.Maps" + ";component/Resources/ap2.data", UriKind.Relative));
need to point here is that "/Com.AMap.Api.Maps" is my library output dll
It works fine.
If I keep the same code in wp8.1 developping
exception appears
An exception of type 'System.ArgumentException' occurred in mscorlib.ni.dll but was not handled in user code
Additional information: The given System.Uri cannot be converted into a Windows.Foundation.Uri. Please see http://go.microsoft.com/fwlink/?LinkID=215849 for details.
I browse http://go.microsoft.com/fwlink/?LinkID=215849
and find that two ways to set the ImageSource correctly.
the ms-appx or ms-appx-web scheme to create an absolute URI.
but it is used for getting a resource in the app package
what I want is getting a resource from my dll
so
What can I do to create a Image instance using way of setting
ImageSource.
Or is there anther way to do what i want?
Thanks!
Just Solve it!
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh965322.aspx
To access files stored inside the same package, but from a class library, use the class library name:
<Image Source="/ClassLibraryName/images/logo.png" />
I am trying to access the WinRT sensors from a Win32 desktop application using C++/CX as mentioned here: https://software.intel.com/en-us/articles/using-winrt-apis-from-desktop-applications
When I include the C++/CX header file it causes an error when building the Win32 project.
Exact error text: "error C1190: managed targeted code requires a '/clr' option."
Since I am not using /clr code at all, this is a confusing error.
Any suggestions? Please educate me if there is a better way to do this.
The error you are getting is because you are compiling some files without /ZW option for compiler. Since you are able compile at least some files with WinRT extensions, but not others, your project configuration is inconsistent.
The option /ZW (enable WinRT extensions) has to be configured on the level of project (and not on the level of individual files). There are two ways to ensure your settings are consistent. First method is through UI in Visual Studio -- you have to go through all platforms/configurations on the project and ensure /ZW is enabled, then got through all indivudual .cpp files, and ensure they don't override project level settings. This is tedious and error prone. The easier method is to open .vcxproj in notepad and do the following:
Add this section at the beginnig of the file, under root Project node:
<ItemDefinitionGroup>
<ClCompile>
<CompileAsWinRT>true</CompileAsWinRT>
</ClCompile>
</ItemDefinitionGroup>
Search and remove any other places where <CompileAsWinRT> is defined.
I'll explain what i'm trying to do (and why) first and then get more into the details.
I'm trying to get Registration Free COM activation working in the context of a language that is compiled JIT. I use Reg-Fre COM because i would like to avoid having to register my COM component and would like this application to be installable without administrative rights.
The JIT compiler is the main executable is signed and contains an embeded manifest. Latest versions of Windows prefer the embeded manifest over an external one, by default (it was the opposite on Windows XP).
Since the JIT is signed, i cannot extract/modify/update it's manifest without breaking the signing. Also, this would introduce complexity in the maintenance of our application (always making sure we embed a new manifest). And there's are also the legal implications of modifying a program for which i don't own the rights.
So, my idea was to try to get the WinSxS activation going thru a Win32 wrapper library for which i would provide a manifest that lists the dependencies. As a proof of concept, i decided to make a simple VB6 app, a C++ Wrapper Library and two COM library (1 in .NET and 1 in VB6).
The wrapper contains 3 methods, one that calls the VB6 COM, one that calls the .NET COM and one that returns a simple string.
As long as everything as my COM are registered, it works, of course.
If i unregister them, provide manifests for the COMs and add them as dependencies to the main executable's manifest, it works.
If i unregister them, provide manifests for the COMs and the C++ Wrapper and add the com as dependencies for the C++ Wrapper and then add the C++ Wrapper as the only dependency in the main executable's manifest, it works.
If i delete my main executable's manifest, the COM calls stop working but the simple string method still works.
Please note that for all my tests, i run a Powershell script that changes the Modified Date of all my files, making sure to trip the activation context cache (manifest).
From there, i started debugging using SXSTrace.exe and setting the COMPlus_LoadLogDir variable. I found out that if my manifest is external, it never gets taken into consideration. I also found out that if i embed it in the .DLL, sxstrace shows it is found, parsed and that the dependencies are found, their manifest found and i get the usual successful context activation lines in the log.
INFO: Parsing Manifest File C:\RegFreeComWrapper\bin\vbCom.MANIFEST.
INFO: Manifest Definition Identity is vbCom,type="win32",version="1.0.0.0".
INFO: Parsing Manifest File C:\RegFreeComWrapper\bin\netCom.MANIFEST.
INFO: Manifest Definition Identity is netCom,processorArchitecture="msil",version="1.0.0.0".
INFO: Activation Context generation succeeded.
End Activation Context Generation.
However, even tho the log says that, my COM calls still dont go thru.
When the call goes thru for the .NET COM call, i get some output in the COMPlus_CLRLoadLogDir configured path.
In this case, i don't get any output.
As soon as i add the manifest that only lists my C++ Wrapper as a dependency to my main executable, everything starts working again. I get a similar output from SXSTrace, but now the COM call works. As mentioned, in all cases, the C++ Wrapper's simple string method works. Meaning that even tho i have no manifest from my main executable, it can still find my .dll and call it.
Seems like the COMs don't work if i dont have the full manifest chain:
Application.Manifest > Wrapper.Manifest > COMs manifests
So, two things here...
1. Is the thing i'm trying to do even possible? (Having dependencies listed only in the manifest of a DLL that belongs to me, without touching the main executable's manifest)
2. If it is possible, i'm probably only missing a small thing to get everything going... what is it ? :)
I can provide all my code/executable as examples, should someone be interested in trying stuff with em.
Got it working!
I modified my C++ Wrapper to use the Activation Context API and force a context activation using 'ActivateActCtx'
http://msdn.microsoft.com/en-us/library/aa374151(v=vs.85).aspx
I wrapped my code with their example's code and made sure to reference my manifests and now all is working fine. No manifest on my main executable!
We have a requirement of creating several Windows 8 apps for tablets. There is a common solution and news apps are created by passing different resource to the same code.
For Mobile it was a cakewalk - Used the Microsoft.Build.Evaluation.Project class to get the xap file.
But for Surface, building from code does not give the direct appx output, while building using MSBuild gives appx as the output.
I tried several methods to avoid calling MSBuild from C#(by creating a Command Process) like creating a zip file - myapp.appx - and then signing it using this c++ code. It didn't workout because of an extern reference and I gave up.
Then I tried to use SignTool.exe by creating a Command Process in C#. That too failed.
So, I am wondering if there is any way to build an appx directly from C# without MSBuild.
The reason why I am trying to avoid MSBuild is to get a status from the build process, which Microsoft.Build.Evaluation.Project.Build() provides.
First try adding a pfx key to your project and then try the build via Microsoft.Build.Evaluation.Project.Build() again. The pfx is required from what I read:
See Candy's answer here:
MSBuild target to create the .appx package
So then the trick would be to use SignTool to get the pfx in the first place and update the project with that pfx, but first see if the above works.
I'm, porting a phone application written using MVVMCross to Windows RT. The application uses SQLite and has a database that is not empty at deploy so I want it to be packaged in the installation folder anc copied to LacalFolder when the application starts.
The database really belongs to the "Core" assembly shared between phone and WinRT but if I put the file in the Core project (in a custom directory called Data), define it as Content and set the Copy Always flag the file does not get copied to the application installation folder.
If I put the file in a directory under the UI project the file gets copied as expected. Any suggestion to avoid keeping two files for the same resource (and the troubles this will cause) ?
Thanks for help
Windows 8 WinRT projects by default use the Content type which does loose packing of files (they are not included in the assembly). If your Core assembly is part of your solution as a project - VS will properly package it copying all the content to the "Core" subfolder of the appx. If you simply have the dll file referenced in your solution - the resource files will not be packaged. The solution in that case is to do something to get these additional files to deploy with the dll. One option is to package the dll as a .vsix together with the assets as described in Tim Heuer's blog post. Another is to do what you did and put the file in the app project. You can add the file to the app project "As Link" to avoid having a copy of the file - it makes Visual Studio create a sort of logical/symbolic link to the file instead of creating a copy - simply right click a folder in the Solution Explorer/app project, select "Add/Existing Item", browse to the file and instead of hitting the "Add" button - use the dropdown triangle on the button to select "Add As Link".