We Keep Coding

Aspose Package document not saving when using doc.save method

I have tried below two methods and ensured that license is updated along with the correct binary. Using .net framework 4.5.2. Below using doc.save method is not working.
Option 1:
doc.Save(LetterTemplateEntity.CRSC_LETTER_TEMPLATE_DESC + doctype,SaveFormat.FormatDocument, SaveType.OpenInWord, this.Response);
Option 2:
doc.Save(this.Response, "LetterTemplateEntity.CRSC_LETTER_TEMPLATE_DESC + doctype", ContentDisposition.Inline, null);

Acccording to the documentation, there are several overloads of the method Document.Save() that you can use :
https://apireference.aspose.com/words/net/aspose.words/document/methods/save/index
However make sure that you are not locking the file you read (after opening the file and executing your program at the same time).
You must use one stream (MemoryStream) for reading and another one for writing.
Also make sure Visual Studio (run as admin) have access to the location where you try to write the file at, in case you run the program from Visual Studio.

Process.Start() exits right away on Windows 7

Process.Start("d:/test.txt"); //simple .txt file works perfectly fine on Windows 8 onward but on Windows 7 (x64) it starts the process and immediately closes it.
I've already tried the following:
Calling through ProcessStartInfo and setting CreateNoWindow=true, UseShellExecute=true and Verb="runas" (though not sure why I had to set this one).
Tried attaching Exit event and it confirms that the process does start but it exits right away and I don't even see the Notepad window open for a blink of a second.
Edit: I've tried it with an image files and few other extensions and they open just perfect. Something wrong with just the .txt files (and/or probably other formats).

I was able to solve this bug just by changing build platform from AnyCPU to specifically x64 (my target machine is x64). This is strange but it solved the problem! Thanks Simon Mourier for this tip.

Its definitely an issue with file association. I have tried it windows 7 and it works fine. Try double clicking on the file and check if it opens in notepad, if it doesn't then configure it to open via notepad.Also you should check the exception that it throws,
If File association is missing then it will launch the Openwith dialog.
If it is associated with wrong program then you can change it manually.
If you want to find association type pragmatically then, I would suggest looking at this answer.
How to I get file type information....

You're saying your code is working fine in other OS and other file formats even in Win 7.
Let's try following checks to verify if things are correct
Verify if notepad.exe is in path
Start -> Run -> notepad.exe should launch Notepad
Double click on a .txt file and see if it automatically opens in Notepad
Verify if Process.Start("notepad.exe") starts an instance of Notepad
var process = Process.Start(file used in step 2); and verify the returned process info in the debug mode and see if says the newly created process is still running or not.

I've had this happen on Windows 7 before. It's likely that your Path environment variable has become corrupted. The maximum number of characters that can be used in the Path variable is 2047. Installing many executables on your machine can overflow the Path variable. Here is a SO discussion that shows some ideas to get around it:
How do you avoid over-populating the PATH Environment Variable in Windows?
If you just need to get notepad running again quickly, you can modify the Path environment variable and just put the system location to Notepad at the beginning of the variable. (ex. "c:\windows\system32\notepad.exe").
And if you're not sure how to modify your Path variable, here is a good how-to:
http://geekswithblogs.net/renso/archive/2009/10/21/how-to-set-the-windows-path-in-windows-7.aspx

What about just using
Process.start("start", "d:\\test.txt")
or
Process.start("explorer", "d:\\test.txt")
or
Process.start("cmd", "/c notepad.exe d:\\test.txt")
If it still doesn't work, try using the straight shellexecute, as described here
Executing another program from C#, do I need to parse the "command line" from registry myself?
https://www.gamedev.net/topic/310631-shellexecuteex-api-call-in-c/

What's the default file path in WinRT/WP 8.1?

Hello fellow programmers.
I recently made a mistake while using the SQLite-NET package for Windows Phone 8.1. When opening a new SQLiteConnection, I would give as parameter to its constructor the string "data.db", without being actually aware of what was going on under the hood. Later on, I noticed that the file wouldn't be deleted, even if I uninstalled the application (since I would have in my app the same entries that I had before uninstalling it); I assume that I should be using the local folder for application data instead.
However, here is the real question: what the hell is the folder where the data.db file was created? I tried to figure it out with the following piece of code:
var file = await StorageFile.GetFileFromApplicationUriAsync(new Uri("ms-appx:///data.db"));
System.Diagnostics.Debug.WriteLine(file.Path);
and what I got as output of the WriteLine method was the path
C:\Data\SharedData\PhoneTools\AppxLayouts\f7529f24-ba24-4fdb-8353-cff9214180a0VS.Debug_ARM.Valbrand\data.db,
which only got me even more confused. I couldn't find any satisfactory info on this, and I would REALLY like to further my understanding of what happened here.
Thanks in advance!

The path you are looking at is the install directory of your app. You have a Silverlight 8.1 app, so the path is slightly different than a Silverlight 8.0 app, but the articles here and here will help you get a rough understanding.
The recommended usage of this directory is to take the resources that you want backed up out of it on first run and move them to the app data container, so they can be backed up by the system.

C:\Data\SharedData\PhoneTools\AppxLayouts\f7529f24-ba24-4fdb-8353-cff9214180a0VS.Debug_ARM.Valbrand\data.db
This is the path on your phone/emulator.
And This is not the location where you can find in your PC.

CurrentAppSimulator.RequestProductPurchaseAsync Win 8.1 doesn't work?

Calling the new
var result = await CurrentAppSimulator.RequestProductPurchaseAsync("id");
doesn't work in Windows 8.1?
But when I call await CurrentAppSimulator.RequestProductPurchaseAsync("id", false); it does work though this method is depreciated and I need the result for consumable In-Apps.
Also by "doesn't work" I mean nothing happens. It doesn't bring up the testing popup windows for "CurrentAppSimulator" and just fails.

My test product ID was just not set right... silly me.

Couple of suggestions: Run the app once calling any method on CurrentAppSimulator. Close your app and look at the WindowsStoreProxy.XML file that the simulator creates in your app folder C:\Users\\AppData\Local\Packages\\LocalState\Microsoft\Windows Store\ApiData\WindowsStoreProxy.xml.
This file is created in UTF-16 format. If you take this file and edit it you will have better luck than if you try to create your own file.
http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.store.currentappsimulator has more details.
Last tip is to remember that this file is never written to. you have to edit it to setup each scenario.
And you'll also have better luck if you create and deploy your own copy for testing.
For me, the file would load but no functions worked when I had it save just a plain ascii file or even after changing it to UTF-8. Had to be saved as UTF-16 to work end-to-end. It would have been nice if the simulator had given some feedback on the ReloadAsync call to save me hours of pain and frustration.

The process cannot access the file because it is being used by another process

I have a set of nightly reports.
Sometimes I get the exception:
The process cannot access the file because it is being used by another process
How do I tell what process is holding on to the file? I am thinking that it is McAfee but I need to prove it.

The problem was the MailMessage in .NET was holding on to the file attachments. I had to do a dispose on the attachment and then it worked.

Use a tool like Process Explorer or Process Monitor.

Attachment data = new Attachment(#"c:\filename");
'send email....
data.Dispose();

here some tool(s) which tells and unlock locked files:
http://ccollomb.free.fr/unlocker/

Confirmed. I had a similar problem and did what Greg said.
In finally block after sending the message, I just put this in there, and it released the file handles:
foreach(Attachment a in message.Attachments) a.Dispose();

Process Explorer > Find > Find
Handle > type in your file name.
Unlocker. Try to open it, if it
has a lock, unlocker will open and
show you the programs that lock it.

GC.Collect() after the dispose should fix it

I was trying to start a Java program and got the message. Looking in Task Manager, there was already a Java task running (looping?) when I killed that process, my process was able to run.

I just had the same problem but in my case i was trying to delete a .mdf file in Visul Studio 2012. There wasn't much information on the error given to help me solve this and so i came here looking for help. Then i realized that even though its a similar problem, it was rather a different process i had to deal with.
What i did was try to delete the .mdf file in windows explorer and then i gave me an error that SQL Server 2008 R2 was in fact holding on to the file even though i had the database deleted. Once i new that, all i had to do was shutdown SQL Server 2008 R2 and tried to delete the file again and it worked.
If you need instructions on how to turn on and off SQL Server 2008 R2, see link below.
Turn on and off SQL Server

Filemon might be the tool you are looking for.
(or even Process Monitor which apparently has replaced FileMon.)