Develop Reference

Weird behaviour on File.Exists() on C# .NET Framework 4.8

I am currently working on a program on WinForms on Visual Studio Community 2022. The program has to check if a file exists on the install directory using File.Exists(), but there is a really weird behaviour that I cannot seem to solve: when debugging (and even running it in the Release mode) the application on VS2022, the value the method returns is false (which is right, because the file doesn't exist at the moment of running the method), but when installing the application, it says the file exists, even when it doesn't, and it can even read the content of that file. Here's the code:
private static string AppPath = $#"{Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)}\eMA\eMA";
public async Task<JArray> GetVersionsJArrayFromComputer()
{
JArray versionsJArray = new JArray();
await Task.Run(async () =>
{
string path = AppPath;
if (!await CheckIfVersionJSONFileExists())
{
if (!await IsRunningAsAdmin())
{
await RunAsAdmin();
Environment.Exit(0);
}
else
{
await SaveVersionJSONFile(await SetVersionsJArrayFromComputer());
}
}
string versionFilePath = $#"{path}\version.json";
string versionFile = File.ReadAllText(versionFilePath);
versionsJArray = (JArray)JsonConvert.DeserializeObject(versionFile);
});
return versionsJArray;
}
private static async Task<bool> CheckIfVersionJSONFileExists()
{
bool fileExists = false;
await Task.Run(() =>
{
string path = AppPath;
string fileName = $#"{path}\version.json";
fileExists = File.Exists(fileName);
});
return fileExists;
}
I created some MessageBoxes to try to debug the application when it is already installed, and this is what it says:
This is the content that it reads from the file (and, in theory, if the file doesn't exist, it shouldn't have any content):
And I don't really know why would it say the file doesn't exist when debugging and then it exists when installed. Any help would be really appreciated.

ASP.NET Core download from a Network Share (sometimes works?)

I have a pretty standard ASP.NET Core 2.2 web app.
I'm running into an issue with downloading files that are stored on a Network Share. We are using a method of impersonation in code (client requirements) to access the file share. Uploading to the share with the provided credentials works fine, so we know that (a) the impersonation is working and (b) the files ARE at the destination. The issue I am having comes from Downloading the file. It's a pretty standard download link that points to an action in a controller that gets the file information from the database and uses two of the database values (PathToFile and Filename) to get the location of the file and pull it back to the controller, followed by returning a file:
var fileRecord = //Get the record from the database.
byte[] bytes = null;
if(fileRecord != null)
{
try
{
string fullPath = $"{fileRecord.PathToFile}\\{fileRecord.Filename}";
await ImpersonationHelper.Impersonate(async () => { bytes = await System.IO.File.ReadAllBytesAsync(fullPath); }, _settings);
}
catch (Exception e)
{
return NotFound();
}
}
return File(bytes, System.Net.Mime.MediaTypeNames.Application.Octet, fileRecord.Filename);
For reference:
public static async Task Impersonate(Action actionToExecute, ApplicationSettings settings)
{
IntPtr tokenHandle = new IntPtr(0);
SafeAccessTokenHandle safeAccessTokenHandle = null;
ImpersonateLogin login = new ImpersonateLogin(settings);
Task<bool> returnValue = Task.Run(() => LogonUser(login.username, login.domain, login.password, 2, 0, out safeAccessTokenHandle));
if (false == returnValue.Result)
{
int ret = Marshal.GetLastWin32Error();
throw new System.ComponentModel.Win32Exception(ret);
}
if(safeAccessTokenHandle != null)
await returnValue.ContinueWith(antecedent => WindowsIdentity.RunImpersonated(safeAccessTokenHandle, () =>
{
actionToExecute();
}));
}
}
Locally, it works fine (we skip the impersonation with an appsetting) and the file comes back and set up as a download in the browser.
On the server, however, it doesn't work, but it also does work. It's strange: Clicking on the link will lead to an error page:
but refreshing this error page (ie. re-requesting that file) over and over again will make it work (usually every 2-4 refreshes will return the file correctly).
Has anyone encountered this, or something like this that can offer some insight?

As it turns out, it (seemingly?) had something to do with the method(s) being async.
Once I removed the (forced) async call to the impersonation, and all async calls right to the "Download" action, it all lined up and works 100% of the time now. From what I could find online, it looks like it was a "timing" issue with async/sync calls. The impersonation would happen AFTER the download file, so the user wouldn't have permission to actually fetch the file to download, but in some cases, the impersonation would happen first, so the file would come back. Making everything "non-async" fixed the issues I was having.

Nodejs equivalent in C# for streaming IO without buffering the content from requestContext

Do we have the equivalent approach of streaming from one source to another destination without buffering it as we have in nodeJs.
In nodejs it emits different events while reading the chunk of data and it doesn't store in memory buffer.
What we have in C#? .net 4.5 or in .netcore2 ?
Nodejs sample with pipe option:
var connector = http.request(options, function(res) {
res.pipe(response, {end:true});//tell 'response' end=true
});
request.pipe(connector, {end:true});

As #Tseng wrote in the comments, buffering is always needed.
I do something similar by streaming a file from Amazon S3 to an HTTP request in ASP.NET Core
public static async Task<Stream> GetFile(string FileId)
{
try
{
TransferUtilityOpenStreamRequest request = new TransferUtilityOpenStreamRequest();
request.BucketName = Config.S3BucketName;
request.Key = FileId;
return await S3Utility.OpenStreamAsync(request);
}
catch (Exception e)
{
if (Globals.Config.IsDebug)
Console.WriteLine("[S3] " + e.ToString());
return null;
}
}
and I have this on my main controller:
[Route("/files/{file_id}.{ext?}")]
public async Task<IActionResult> GetFile(string file_id, string ext)
{
return File(await Globals.GetFile(file_id), BakaMime.GetMimeType(ext));
}
The function BakaMime.GetMimeType(ext) is a function that gets a mime type from the extension, just an FYI.
Hope this helps show how you can stream data from one location to another.

Dropbox.Api failing to upload large files

I am uploading files to dropbox using the following code.
I am using the nuget package Dropbox.Api and getting the exception System.Threading.Tasks.TaskCanceledException("A task was canceled.")
From this SO Question it appears to be a timeout issue.
So how do I modify the following code to set the timeout.
public async Task<FileMetadata> UploadFileToDropBox(string fileToUpload, string folder)
{
DropboxClient client = new DropboxClient(GetAccessToken());
using (var mem = new MemoryStream(File.ReadAllBytes(fileToUpload)))
{
string filename = Path.GetFileName(fileToUpload);
try
{
string megapath = GetFullFolderPath(folder);
string megapathWithFile = Path.Combine(megapath, Path.GetFileName(Path.GetFileName(filename))).Replace("\\", "/");
var updated = client.Files.UploadAsync(megapathWithFile, WriteMode.Overwrite.Instance, body: mem);
await updated;
return updated.Result;
}
catch (Exception ex)
{
return null;
}
}
}

Try creating and initializing the client like this:
var config = new DropboxClientConfig();
config.HttpClient.Timeout = new TimeSpan(hr, min, sec); // choose values
var client = DropboxClient(GetAccessToken(), config);
Reference:
http://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_DropboxClient__ctor_1.htm

One more thing to keep in mind is UploadAsync will not work for files larger than 150MB as per documentation. One will have to use UploadSessionStartAsync based implementation for it. I was making the mistake without realizing it and it took ages for me to fish the problem out.

Windows Phone 8 file are not persisted across app restart

I'm writing my first Windows Phone 8 app, and I'm just trying something simple. Read / Write file. Here's my two methods:
public static async Task<Week> Load()
{
StorageFolder folder = ApplicationData.Current.LocalFolder;
try
{
StorageFile mealsFile = await folder.GetFileAsync("file.txt");
if (mealsFile != null)
{
using (var stream = await mealsFile.OpenAsync(FileAccessMode.Read))
{
var serializer = new DataContractSerializer(typeof(List<MyTypeHere>));
var w = (List<MyTypeHere>)serializer.ReadObject(stream.AsStreamForRead());
if (w != null)
MyWeek.WeekList = new ObservableCollection<MyTypeHere>(w);
}
}
}
catch(FileNotFoundException fEx)
{
MyWeek = new Week();
}
return MyWeek;
}
public static async Task<bool> Save()
{
try
{
StorageFolder folder = ApplicationData.Current.LocalFolder;
StorageFile mealsFile = await folder.CreateFileAsync("file.txt", CreationCollisionOption.ReplaceExisting);
using (var stream = await mealsFile.OpenAsync(FileAccessMode.ReadWrite))
{
using (var sw = stream.GetOutputStreamAt(0))
{
var serializer = new DataContractSerializer(typeof(List<MyTypeHere>));
serializer.WriteObject(sw.AsStreamForWrite(), MyWeek.WeekList.ToList());
await sw.FlushAsync();
}
}
MyWeek = null;
return true;
}
catch(Exception ex)
{
return false;
}
}
I'm calling the Save (with breakpoint it works fiine), then call Load (with breakpoint) which load the file, the file exists and it populate my object graph.
When I close the app and restart it, the catch of the FileNotFoundException is caught. Why?
From what I can see the Local Folder is supposed to be persisting the file. What I'm missing that obviously should be obvious...
Thanks
Edit:
I'm using the Windows Phone emulator, and when I close it and hit F5 on Visual Studio, the file is not there anymore.

Apparently by closing the emulator, the files in Local Storage are lost, thanks to #cdndevs via Twitter. I was closing the emulator each time I was stopping debugging instead of letting the emulator simply "stay" there between restart.
By stopping debugging and restarting the app without closing the emulator, the files are there. Well, not super intuitive I must admit, or it might just be me. Hope that help other people like me ;).