Even though I have an app version set as 3.0.4 both in WMAppManifest as Package.appxmanifest, Windows.ApplicationModel.Package.Current gives me 1.0.0.0
Any clues? This is how I'm trying to retrieve
var myPackage = Windows.ApplicationModel.Package.Current;
var ver = myPackage.Id.Version;
string appVer = string.Format("{0}.{1}.{2}.{3}", ver.Major, ver.Minor, ver.Build, ver.Revision);
If you have WMAppManifest in your project, your app is a Silverlight one, so the best way si to parse the WMAppManifest file and get the version from there, here is a sample: https://github.com/igorkulman/Kulman.WP8/blob/master/Kulman.WP8/Code/ManifestHelper.cs
You can set your app version in the AssemblyInfo.cs file like this :
[assembly: AssemblyVersion("1.0.*")]
To retrieve it do this :
var nameHelper = new AssemblyName(Assembly.GetExecutingAssembly().FullName);
string sMyAppVersion = nameHelper.Version.ToString();
If this is a 8.1 universal app. Go to Package.appxmanifest file and click the packaging tab. There you can verify what values you are passing for Version (Major, Minor,Build,Revision)
Hope this helps.
Related
I am currently moving an ASP.NET application made by a third party from Windows to Linux. I read the documentation and nothing indicates this should be a problem, but sadly
var profile = new CredentialProfile(profileName, credentials) {
Region = RegionEndpoint.EUWest1
};
var netSDKFile = new NetSDKCredentialsFile();
netSDKFile.RegisterProfile(profile);
throws the following exception
Unhandled Exception: Amazon.Runtime.AmazonClientException: The encrypted store is not available. This may be due to use of a non-Windows operating system or Windows Nano Server, or the current user account may not have its profile loaded.
at Amazon.Util.Internal.SettingsManager.EnsureAvailable()
at Amazon.Runtime.CredentialManagement.NetSDKCredentialsFile..ctor()
Is the Amazon .NET SDK(or a part of it) not supported on Linux? If that is the case, is there a possible workaround?
For the most part there is very little that isn't supported on Linux that is supported on Windows. Off of the top of my head I can't think of anything besides NetSDKCredentialsFile which is due to the fact it uses Win32 API to encrypt credentials.
You can use SharedCredentialsFile to register a profile in the credentials file stored under ~/.aws/credentials. This is the same credential stored supported by all of the other AWS SDK and Tools.
Following on from Norm's answer, I found this resource that explained how to use Shared Credentials: https://medium.com/#somchat/programming-using-aws-net-sdk-9ce3f5119633
This is how I was previously using NetSDKCredentials, which won't work for Linux/Mac OS:
//Try this code on a non-Windows platform and you will see the above error
var options = new CredentialProfileOptions
{
AccessKey = "access_key",
SecretKey = "secret_key"
};
var profile = new CredentialProfile("default", options);
profile.Region = RegionEndpoint.USWest1;
NetSDKCredentialsFile file = new NetSDKCredentialsFile();
file.RegisterProfile(profile);
But I was then able to use this example to use SharedCredentials:
var credProfileStoreChain = new CredentialProfileStoreChain();
if (credProfileStoreChain.TryGetAWSCredentials("default", out AWSCredentials awsCredentials))
{
Console.WriteLine("Access Key: " + awsCredentials.GetCredentials().AccessKey);
Console.WriteLine("Secret Key: " + awsCredentials.GetCredentials().SecretKey);
}
Console.WriteLine("Hello World!");
You'll then be able to see your code is able to access the keys:
Access Key: A..................Q
Secret Key: 8.......................................p
Hello World!
I then used System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform() (as I am using this code on both Windows and Linux), to determine which credentials to use:
using System.Runtime.InteropServices;
//NETSDK Credentials only work on Windows - must use SharedCredentials on Linux
bool isLinux = System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform(OSPlatform.Linux);
if (isLinux) {
//Use SharedCredentials
} else {
//Use NetSDKCredentials
}
You may find this section of the AWS documentation helpful, too: https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-config-creds.html#creds-locate
I'm trying to use Assembly to get app version, but it doesn't have GetExecutingAssembly() method on Universal App, how can I do it?
string version = "V " + Assembly.GetExecutingAssembly().FullName.Split(',')[1].Split('=')[1];
You can get through to the assembly via reflection:
string version = this.GetType().GetTypeInfo().Assembly.GetName().Version.ToString(4);
(from Chris Sienkiewicz's Blog)
I had to use the following to get the version string for a Windows 10 Universal App:
var version =
Application
.Current
.GetType()
.AssemblyQualifiedName
.Split(' ')[2]
.Split('=')[1]
.Replace(",", "");
I am trying to write a line of text to a text file. On the emulator or running from VS on the device, it works perfectly but when downloaded from the store, this code emits the error:
System.UnauthorizedAccessException: Access to the path
'C:\Data\Programs\{XXXXXX-XXXXX-XXX-XXXXX}\Install\Data\results.csv' is denied.
Here is my code:
var path = "Data/results.csv";
var uri = new Uri(path, UriKind.RelativeOrAbsolute).ToString();
using (var rd = new StreamWriter(uri, true))
{
var line = String.Format("{0};{1}", field1, field2);
rd.WriteLine(line);
rd.Close();
}
Am I doing something wrong? How can the code work on development?
Use:
var iso = IsolatedStorageFile.GetUserStoreForApplication();
It gets the storage that your app can use on users phone. You can then create directories (or files) for example:
iso.CreateDirectory("Data");
Why it works in emulator or on your device? I'd guess because MS does not care about access rights here.
in my Silverlight Windows Phone 7/8 projects I always used these methods/classes to get informations about the user phone:
Microsoft.Phone.Info.DeviceStatus.DeviceFirmwareVersion;
System.Environment.OSVersion.Version;
Microsoft.Phone.Info.DeviceStatus.DeviceName;
Microsoft.Phone.Info.DeviceStatus.DeviceManufacturer;
But now in Windows Phone 8.1 runtime they are missing. Are there some alternatives? My app doesn't use networking.
Thanks and sorry for bad english.
You can use the EasClientDeviceInformation class
e.g.
var deviceInfo = new EasClientDeviceInformation();
var manufacturer = deviceInfo.SystemManufacturer;
var name = deviceInfo.SystemProductName;
var firmwareVersion = deviceInfo.SystemFirmwareVersion;
var osVersion = "8.1"; // Only 8.1 so far. No os version method exists afaik in 8.1
Universal/WinRT apps only work in wp 8.1, so the OS version can only be 8.1. When they make wp8.2 or wp9, they'll probably add a way to check what OS version is installed...
If you're looking for the firmware version, you can get it with:
Windows.Security.ExchangeActiveSyncProvisioning.EasClientDeviceInformation deviceInfo = new Windows.Security.ExchangeActiveSyncProvisioning.EasClientDeviceInformation();
var firmwareVersion = deviceInfo.SystemFirmwareVersion;
How to put\save files into your application directory? (adobe air) (code example, please)
It's not recomended but it is possible. Construct your File reference like this:
var pathToFile:String = File.applicationDirectory.resolvePath('file.txt').nativePath;
var someFile:File = new File(pathToFile);
You can't write to your AIR app's Application Directory, it's not allowed. You can however write to a folder that your AIR app creates in the user's directory, called the Application Storage Directory. If you need config files and the like, that's probably the best place to put them. See 'applicationDirectory' in the docs link below:
http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/
#glendon
if you try to save directly to applicationDirectory it will indeed throw an error, but it seems you can move the file in the filesystem. i used the code below after yours:
var sourceFile:File = File.applicationStorageDirectory.resolvePath ("file.txt");
var pathToFile:String = File.applicationDirectory.resolvePath ('file.txt').nativePath;
var destination:File = new File (pathToFile);
sourceFile.moveTo (destination, true);
the reason why you 'shouldnt' use the application folder is because not all users have rights to save files in such folder, while everyone will in applicationStorageDirectory.
The accepted answer works!
But if I do this instead:
var vFile = File.applicationDirectory.resolvePath('file.txt');
var vStream = new FileStream();
vStream.open(vFile, FileMode.WRITE);
vStream.writeUTFBytes("Hello World");
vStream.close();
It will give SecurityError: fileWriteResource. However, if I use applicationStorageDirectory instead, the above code will work. It'll only NOT work if it's applicationDirectory. Moreover, Adobe's documentation also says that an AIR app cannot write to its applicationDirectory.
Now, I wonder if it's a bug on Adobe's part that they allow writing to the applicationDirectory using the way suggested by the accepted answer.
try this.
var objFile:File = new File(“file:///”+File.applicationDirectory.resolvePath(strFilePath).nativePath);
the output would be like this…
file:///c:\del\userConf.xml
This will work fine.
If you want write file into ApplicationDirectory, right?
Please don't forget for write for nativeprocess via powershell with registry key for your currect adobe application ( example: C:\Program Files (x86)\AirApp\AirApp.exe with RunAsAdmin )
nativeprocess saves new registry file
AirApp will restarts into RunASAdmin
AirApp can be writable possible with file :)
Don't worry!
I know that trick like sometimes application write frist via registry file and calls powershell by writing nativeprocess into registry file into registry structures.
Look like my suggestion from adobe system boards / forum was better than access problem with writing stream with file :)
I hope you because you know my nice trick with nativeprocess via powershell + regedit /s \AirApp.reg
and AirApp changes into administratived AirApp than it works fine with Administratived mode :)
Than your solution should write and you try - Make sure for your writing process by AirApp.
this function gives your current air application folder which bypasses the security problem:
function SWFName(): String {
var swfName: String;
var mySWF = new File(this.loaderInfo.url).nativePath;
swfName= this.loaderInfo.loaderURL;
swfName = swfName.slice(swfName.lastIndexOf("/") + 1); // Extract the filename from the url
swfName = new URLVariables("path=" + swfName).path; // this is a hack to decode URL-encoded values
mySWF = mySWF.replace(swfName, "");
return mySWF;
}