Develop Reference

my roaming data dosen't sync between devices

I made a UWP application. I use the roamingdata.I save the setting by this:
public static void WriteCode(string pwd)
{
ApplicationDataContainer RoamingSettings = ApplicationData.Current.RoamingSettings;
RoamingSettings.Values["Code"] = EncryptHelper.PwdEncrypt(pwd);
}
I read the setting by this:
public static string GetCode()
{
ApplicationDataContainer RoamingSettings = ApplicationData.Current.RoamingSettings;
string str = (String)RoamingSettings.Values["Code"];
if (!String.IsNullOrEmpty(str))
return str;
else
return EncryptHelper.PwdEncrypt("123");
}
I complete the application and upload to windows store and passed check. Then I download this app on my phone.
I change the ApplicationData.Current.RoamingSettings on phone. I write something to the ApplicationData.Current.RoamingFolder on my phone.
Next I closed the app on my phone and download the app on my PC. But when I opened the app on my PC, I found that the ApplicationData.Current.RoamingSettings and the ApplicationData.Current.RoamingFolder didn't change anything.
I checked the C:\Users\XXX\AppData\Local\Packages\XXX\RoamingState on my PC,there was nothing. I checked C:\Users\XXX\AppData\Local\Packages\XX\Settings on my PC,there was roaming.lock and settings.dat. But I can't read the lastest settings and roaming data that I haved added on my phone anymore.
I have waited for 2 hours, there was no change on my PC.
there is something that I should state first:
1 All the deploy work was done by windows store.
2 I check my PC application setting after closed the app on phone. I even shut down my mobile phone to observe the change to my PC.
what's wrong with my code? or what's wrong with the roamingdata mechanism? I need an answer, thank you!

The code you've posted is right. However, there are some possible reasons for the failure of roaming data sync:
Any user can benefit from roaming app data if they use a Microsoft account to log on to their device. However, users and group policy administrators can switch off roaming app data on a device at any time. If a user chooses not to use a Microsoft account or disables roaming data capabilities, she will still be able to use your app, but app data be local to each device.
Keep in mind that roaming data is associated with a user's Microsoft account. Roaming data will only sync if a user logs into her devices using the same Microsoft account and installs the app on several devices.
Don't use roaming for data that relies on instant syncing. Windows doesn't guarantee an instant sync; roaming could be significantly delayed if a user is offline or on a high latency network.
Roaming of settings is not instant. The system weighs several factors when determining when to send the data. We can detect whether new roaming data has arrived on the local device by listening for the ApplicationData.DataChanged event. This event occurs when app data has just finished syncing from the cloud. Any time a device receives new roaming data, the DataChanged event will fire, passing in the updated ApplicationData object. This lets us make any adjustments to our app when data has changed.
For important, time critical settings, use the HighPriority setting associated with RoamingSettings like following:
// High Priority setting, for example, last page position in book reader app
roamingSettings.values["HighPriority"] = "65";
This is a special key in the roaming settings we can use for data we need to sync immediately. Adding HighPriority to any setting will have it synced as quickly as possible.
Don't roam large sets of app data. There's a limit to the amount of app data an app may roam; use RoamingStorageQuota property to get this maximum. If an app hits this limit, no data can roam until the size of the app data store no longer exceeds the limit.
The name of each setting can be 255 characters in length at most. Each setting can be up to 8K bytes in size and each composite setting can be up to 64K bytes in size. The sync engine may limit the total size of settings and files that can roam. It’s important to keep track of the amount of data you’re attempting to roam. If the total amount of data you’re attempting to sync exceeds the limit, then nothing will sync between the devices.
App data only roams between installed apps with the same version number. For example, devices on version 2 will transition data between each other and devices on version 3 will do the same, but no roaming will occur between a device running version 2 and a device running version 3. If you install a new app that utilized various version numbers on other devices, the newly installed app will sync the app data associated with the highest version number.
If you are using versioning in your roaming date, please make sure you are dealing with the right version.
These are some possible reasons that can cause roaming data doesn't sync between devices. For more info, please check Roaming data in Store and retrieve settings and other app data.

SerialPort.GetPortNames() returns incorrect port names

While c# is not my primary programming language, I'm maintaining such a program for a couple of years now. This program connects to a device on a serial port and works from Windows XP up to 8.1. One specific "feature" is that it uses .NET Framework 2.0.
With some users upgrading to Windows 10 we've got complains that the program cannot detect/open the COM port of the device. We have confirmed this on our own test systems with clean Win10 installation.
It turns out that the function SerialPort.GetPortNames() returns incorrect port names and adds 'strange' characters after the port name.
For example:
COM3吀
COM3䡢
COM3゠
Etc. When I refresh the list, every time another character (or two) shows up after the number.
The test code is super straightforward:
string[] portNames = System.IO.Ports.SerialPort.GetPortNames();
log("Available ports:");
foreach (string PortAvailable in portNames)
{
log(PortAvailable);
}
Where the log function mearly adds a line to a standard TextBox on the form:
txtLog.Text += Msg + Environment.NewLine;
This works in every other Windows version.
I've checked the registry and all looks fine there also.
Does anybody has an idea about this?
I'm suspecting that .NET Framework 2.0 is not 100% compatible anymore, although you can enable it in the Windows features and it seems that the program itself runs fine (besides my serial port problem). I'm a bit scared to upgrade to a newer .NET, let alone that we've VisualStudio 2008 for c# (max=.NET 3.5). Note that the program still needs to run on Windows XP also (POS version is still maintained by Microsoft).
ADDED:
I've "upgraded" a test program to .NET 3.5, and still having exactly the same issue.
Next step is to install a new VisualStudio (it appears that it is free nowadays?? Should I check for privacy settings in Studio also? ;-).
ADDED 2:
Installed VisualStudio 2015 and made multiple builds with different .NET framework versions. v2.0 and 3.5 still adding the strange character. But in v4.0 and up this issue seems te be solved! Now to get the original program compiled and working for the newer Framework.
But I find this issue really strange and would expect that this would hit more .NET functions and more programs.

I've seen the strange characters too. My solution is using Regular Expressions to filter out the number portion of the comm port name.
Dim ports As New Devices.Ports
For Each s As String In ports.SerialPortNames
s = Regex.Replace(s, "\D*(\d+)\D*", "$1")
Debug.WriteLine(s)
Next

I've had this exact same problem with USB CDC serial devices, handled by the new rewritten Windows 10 usbser.sys driver.
The garbage characters are often digits, so removing non-digits isn't a reliable way to work around it. For my solution, look at my last post on this thread here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/a78b4668-ebb6-46aa-9985-ec41667abdde/ioportsserialportgetportnames-registrykeygetvalue-corruption-with-usbsersys-driver-on-windows?forum=netfxbcl
..there is code there that'll go through the registry, find usbser ports, and return their unmangled names. Beware that it doesn't return all serial ports, just ones provided by that driver. The code works on Windows XP through to 10.
The underlying problem is that the usbser.sys driver creates a registry entry, and on .NET (at least up to 3.5) the GetPortNames() function tries to read those registry keys and gets corrupted data. I've reported this to Microsoft, both via that forum (assuming they read it) and using the built-in Windows 10 beta error reporting tool. Maybe one day there will be a fix.

As you say the program works after enabling the windows feature:
.NET 2.0,3.0,3.5 isn't enabled by default on Windows 8/8.1/10. The files aren't stored on the install media/wim.
It can be enabled with the DISM command from windows update or a local source.
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

check this out: http://forums.radioreference.com/uniden-tech-support/317887-windows-10-uniden-usb-driver-5.html
For a work around to fix the Win 10 serial port not working caused by strange characters after the port name.
Go in to the Registry with regedit.exe.
Navigate to "HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALC OMM"
Make note of the comm port name.
Append a "0" or any character to the comm port name.
Change the comm port name back to what it was in step 3.
It worked for me.
Baldur

string[] ports = SerialPort.GetPortNames();
for (int i = 0; i<ports.Length;i++)
{
string mystr = ports[i];
if (((mystr[mystr.Length-1]) >= 0x30) & ((mystr[mystr.Length-1]) <= 0x39))
{
}
else
{
mystr = mystr.Remove(mystr.Length-1);
}
ports[i] = mystr;
}

VS2013 publish Web deployment task failed The file is in use

I am using VS2013 Premium to publish a site to Windows Server 2012.
All files publish ok except these:
SqlServerTypes\x64\msvcr100.dll
SqlServerTypes\x64\SqlServerSpatial110.dll
SqlServerTypes\x86\msvcr100.dll
SqlServerTypes\x86\SqlServerSpatial110.dll
I get this kind of errors for each of the above files I tried to publish:
Web deployment task failed. (The file 'msvcr100.dll' is in use. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
Interrestingly, these files were published the first time (when they were not on the server), then they are no longer overwritten. Tried with 2 different web servers.
I have followed the guide here:
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
...But it only managed to put the site offline (VS is placing the app_offline.htm) but publish still fails with the same error.
All other files publish perfectly.
Any ideas?

You can take you app offline during publishing which hopefully should free up the lock on the file and allow you to update it.
I blogged about this a while back. The support outlined was shipped inside of the Azure SDK and Visual Studio Update. I don't remember the exact releases but I can find out if needed. Any update dating around/after that blog post should be fine.
Prerequisites:
VS 2012 + VS update / VS 2013 + VS Update / VS2015
MSDeploy v3
Note: if you are publishing from a CI server the CI server will need the updates above as well
Edit the publish profile
In VS when create a Web Publish profile the settings from the dialog are stored in Properties\PublishProfiles\ as files that end with .pubxml. Note: there is also a .pubxml.user file, that file should not be modified
To take your app offline in the .pubxml file add the following property.
<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
Notes
ASP.NET Required
The way that this has been implemented on the MSDeploy side is that an app_offline.htm file is dropped in the root of the website/app. From there the asp.net runtime will detect that and take your app offline. Because of this if your website/app doesn't have asp.net enabled this function will not work.
Cases where it may not work
The implementation of this makes it such that the app may not strictly be offline before publish starts. First the app_offline.htm file is dropped, then MSDeploy will start publishing the files. It doesn't wait for ASP.NET to detect the file and actually take it offline. Because of this you may run into cases where you still run into the file lock. By default VS enables retrys so usually the app will go offline during one of the retrys and all is good. In some cases it may take longer for ASP.NET to respond. That is a bit more tricky.
In the case that you add <EnableMSDeployAppOffline>true</EnableMSDeployAppOffline> and your app is not getting taken offline soon enough then I suggest that you take the app offline before the publish begins. There are several ways to do this remotely, but that depends on your setup. If you only have MSDeploy access you can try the following sequence:
Use msdeploy.exe to take your site offline by dropping app_offline.htm
Use msdeploy.exe to publish your app (_make sure the sync doesn't delete the app_offline.htm file_)
Wait some amount of time
Publish the site
Use msdeploy.exe to bring the app online by deleting app_offline.htm
I have blogged how you can do this at http://sedodream.com/2012/01/08/howtotakeyourwebappofflineduringpublishing.aspx. The only thing that is missing from that blog post is the delay to wait for the site to actually be taken offline. You can also create a script that just calls msdeploy.exe directly instead of integrating it into the project build/publish process.

I have found the reason why the solution at
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
did not work for the original poster, and I have a workaround.
The issue with the EnableMSDeployAppOffline approach is that it only recycles the app domain hosting the application. It does not recycle the app pool worker process (w3wp.exe) which the app domain lives in.
Tearing down and recreating the app domain will not affect the Sql Server Spatial dlls in question. Those dlls are unmanaged code which are manually loaded via interop LoadLibray calls. Therefore the dlls live outside the purview of the app domain.
In order to release the files locks, which the app pool process puts on them, you need to either recycle the app pool, or unload the dlls from memory manually.
The Microsoft.SqlServer.Types nuget package ships a class which is used to load the Spatial dlls called SqlServerTypes.Utilities. You can modify the LoadNativeAssemblies method to unload the unmanaged dlls when the app domain is unloaded. With this modification when msdeploy copys the app_offline.htm the app domain will unload and then unload the managed dlls as well.
[DllImport("kernel32.dll", SetLastError = true)]
internal extern static bool FreeLibrary(IntPtr hModule);
private static IntPtr _msvcrPtr = IntPtr.Zero;
private static IntPtr _spatialPtr = IntPtr.Zero;
public static void LoadNativeAssemblies(string rootApplicationPath)
{
if (_msvcrPtr != IntPtr.Zero || _spatialPtr != IntPtr.Zero)
throw new Exception("LoadNativeAssemblies already called.");
var nativeBinaryPath = IntPtr.Size > 4
? Path.Combine(rootApplicationPath, #"SqlServerTypes\x64\")
: Path.Combine(rootApplicationPath, #"SqlServerTypes\x86\");
_msvcrPtr = LoadNativeAssembly(nativeBinaryPath, "msvcr100.dll");
_spatialPtr = LoadNativeAssembly(nativeBinaryPath, "SqlServerSpatial110.dll");
AppDomain.CurrentDomain.DomainUnload += (sender, e) =>
{
if (_msvcrPtr != IntPtr.Zero)
{
FreeLibrary(_msvcrPtr);
_msvcrPtr = IntPtr.Zero;
}
if (_spatialPtr != IntPtr.Zero)
{
FreeLibrary(_spatialPtr);
_spatialPtr = IntPtr.Zero;
}
};
}
There is one caveat with this approach. It assumes your application is the only one running in the worker process that is using the Spatial dlls. Since app pools can host multiple applications the file locks will not be released if another application has also loaded them. This will prevent your deploy from working with the same file locked error.

There are known issues with IIS and file-locks (why they aren't solved yet i dont know).
The question i want to ask however is if you even need to re-deploy these files?
I recognize the file-names and recall them to be system-files which should either already be present on the server or simply not need to be re-deployed.
I am not very experienced when it comes to IIS but i have ran into this problem before and several of my more experienced co-workers have told me that this is as i said a known IIS-issue and i believe the answer to your question is:
Avoid deploying unnecessary files.
try again
Reset website
try again
iisreset

I think what would be the easiest thing to do is to make these dll's as CopyLocal as true. I am assuming these dll's are pulled out from program files folder. Try marking them as copylocal true and do a deployment.Try to stop any IIS local process running in your local machine.

Watch out you don't have one of those new-fangled cloud backup services running that is taking file locks - and also you don't have things open in explorer or a DLL inspection tool.
I think it's kind of ridiculous that MS doesn't make better provisions for this problem. I find that 9 times out of 10 my deployment works just fine, but then as our traffic increases that can become 1 in 10 times.
I am going to solve the problem with :
two applications MySite.A and MySite.B, where only one is running at a time.
I always then deploy to the dormant site.
If there's a problem during the deployment it will never cause the whole site to go down.
If there's a major problem after deployment you can revert back very easily.
Not quite sure how I'm implementing it, but I think this is what I need to do.

ClickOnce fails to initialize with no network

I have an application that I have just added ClickOnce to as an update method. I'm about to pull it and do something else, even after working through all the gotchas of dealing with ClickOnce in a moderately complex application. Well, it's not even a complex application, but it's going onto dedicated hardware, so I have a few odd requirements, like completely transparent and automatic updates, no odd little pup-up windows, etc. The main one is that the application starts and takes over the system at boot.
Where this causes trouble for ClickOnce is that when the system first boots, there is no network - the Wi-Fi is still getting started and connecting. The application handles this, checking for the network to get started and then connecting to our server. ClickOnce is a different matter. If there is no network when the application starts, then all the ApplicationDeployment functions will not work, even after the network is started.
So, for example, I use something like this to get the version:
if (ApplicationDeployment.IsNetworkDeployed)
Version = ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString();
else
Version = "unknown";
If I run the application at boot (that is, before the network is working), this code will return "unknown" for the rest of the application run, even after the network is up. If I shut down the application and restart it, it shows the deployed version. So technically, the IsNetworkDeployed is returning an incorrect value. The application WAS network deployed; it's just not on a network NOW. I'll probably post this as a bug over on MSDN.
BTW, the application does not actually require a network to run, so at startup, I can't take the path of "wait until the network is ready, then restart the application automatically". The hardware can move around, and may be in the middle of nowhere with no available network at all. I still have to deal with that (and I don't actually return "unknown" for that case, I just pull the version from the assembly). And if the problem was just getting a version, I wouldn't care, but this means that there is no way to ever update the application, since it always starts with no network, and it will never get to my code to check for, download, and auto-update the application.
Before I write off all my ClickOnce work, I was wondering if anyone knew of a way to reinitialize ApplicationDeployment, so that it will figure out that there is a network and enable all that ClickOnce goodness.

This is basically what that check is doing:
private static bool _isNetworkDeployed;
private static bool _isNetworkDeployedChecked;
public static bool IsNetworkDeployed
{
get
{
if (!_isNetworkDeployedChecked)
{
_isNetworkDeployed = (
AppDomain.CurrentDomain != null &&
AppDomain.CurrentDomain.ActivationContext != null &&
AppDomain.CurrentDomain.ActivationContext.Identity != null &&
AppDomain.CurrentDomain.ActivationContext.Identity.FullName != null);
//_isNetworkDeployed = ApplicationDeployment.IsNetworkDeployed;
_isNetworkDeployedChecked = true;
}
return _isNetworkDeployed;
}
}
We ran into the same issue with ClickOnce and reverse engineered the check. You could modify this to do your own checking prior to calling the .NET version.

How to use C# to check if WUA is set to "Install updates automatically (recommended)?"

We have a server running a 6 day job that just reset, because Windows Update Agent (WUA) automatically rebooted the machine to install updates.
I would like to alter my C# app to warn the user if this setting is on in the future, so we don't end up suffering from random reboots, which forces a restart of said 6-day job, wasting 4 days of CPU time.
Does any know if it is possible to check within WUA that "Important Updates" is set to "Install updates automatically (recommended)", within C#?

There is an API for the Windows Update Agent (WUA), its general use is described at:
Install Windows Update Using C#
Here is the C# code:
// See http://techforum4u.com/entry.php/11-Install-Windows-Update-Using-C
var auc = new WUApiLib.AutomaticUpdatesClass();
if (auc.Settings.NotificationLevel ==
AutomaticUpdatesNotificationLevel.aunlScheduledInstallation)
{
Console.Write("{0}Warning W20120307-1107. Windows Update Agent (WUA) is capable of rebooting the PC automatically. Recommend switching this off for the duration of this 6-day batch process.\n", NPrefix());
}
After adding c:\WINDOWS\system32\wuapi.dll, if you get a compile error, see Interop type cannot be embedded.
Note that this approach will only work on Windows 7, add a try/catch around it to prevent a crash on Windows XP. See the forums for how to get it working on XP (you have to reference WUA version 1, WUA for Windows 7 is version 2).