Some background:
we have a windows application (c#) that locate in the system try.
that simple application is a basically shortcuts manger for other application and messaging between the workers.
one of the application is an Access 2007 application (connected to sqlserver) - the client works with ACCESS Runtime 2007 (latest version)
THE problem is that we can not launch the Access application correctly from the C# application.
THE problem is only on windows 7 (we don't have vista) - [on XP OS everything works fine)
"correctly" - meaning that the Access application running but the Ribbon Bar is missing some Icons (strange). also some functionality like open the Outlook is not working.
Some more Info:
- IF we put shortcut on the client desktop to the Access application everything ok.
- The C# application have no problem to launch other EXE file.
- The C# application include Manifest file (run as admin on Win 7).
The Original code is very simple (Works only in XP):
System.Diagnostics.Process.Start(AppPath);
The 'Open EXE' code that works (Works on XP and Win7)-[not working with Access Application]
Process Proc= new Process();
Proc.StartInfo.UseShellExecute = false;
Proc.StartInfo.FileName = Application.StartupPath + #"\PasswordManager.exe";
Proc.Start();
We try many codes with no success like [NOT WORKING]:
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.EnableRaisingEvents = false;
proc.StartInfo.FileName = sAccPath;// msaccess Path;
proc.StartInfo.Arguments = #"""" + AppPath+ #"""";
proc.Start();
We also try to add [NOT WORKING]:
System.OperatingSystem osInfo = System.Environment.OSVersion;
if (osInfo.Version.Major > 5)
proc.StartInfo.Verb = "runas";
Helppppppppppp!!!
Thanks
I could be wrong on this, but my guess is that it's running in reduced functionality mode due to your not defining a trusted location from which it can run. I don't know how this is done in code, but if you launch A2007, it's on the Office menu under Access Options (I'm posting from menu, as I mostly use A2003 and don't want to wait through the re-registration process).
We uninstall current OFFICE SBE 2007 and Install a newest version of OFFICE SBE 2007.
everything works fine now.
our conclusion is that Office SBE 2007 first version (instaled at client computer) doesn't work well with Access Runtime 2007.
(weird, but work)
David, Thank You very much.
Related
I have a c# console application running daily as a scheduled task.
Recently I've added a new functionality to send an e-mail with an attached pdf report, using Access 2010 built-in pdf export:
using MsAccess = Microsoft.Office.Interop.Access;
//(...)
AccApp = new MsAccess.Application();
AccApp.Visible = false;
AccApp.OpenCurrentDatabase(DBPathname, false);
AccApp.DoCmd.OutputTo(MsAccess.AcOutputObjectType.acOutputReport, "GMB_CSS_Report", "PDFFormat(*.pdf)", ReportFilename, false, Type.Missing, Type.Missing, MsAccess.AcExportQuality.acExportQualityPrint);
//(...)
When I run the new version interactively on the command line it works well, exporting the report as a PDF to the designated path\file.
But when I run it from task manager, using the same credentials, it crashes on the DoCmd.OutputTo(...) statement with the error:
(System.Runtime.InteropServices.COMException) Microsoft Access can't save the output data to the file you've selected.
That does not make any sense, as the application successfuly writes several other files to the same folder, running either from the console or from the task manager.
I've also found that the application runs without the error as a scheduled task on a third PC, not integrated in the company AD domain (the production and dev hosts are on the domain), even though all 3 hosts have the same s/w level (Win7 SP1, Access 2010 updated to latest patches via Windows Update).
This is bizarre... am I missing something here ? Any suggestions will be greatly appreciated.
Thanks in advance.
I think that your problem is in the "PDFFormat(*.pdf)" constant string.
The right one for PDF is this:
public const string acFormatPDF = "PDF Format (*.pdf)";
And this is for RTF:
public const string acFormatRTF = "Rich Text Format (*.rtf)";
I still have got problems with the same function on a 64Bit version of Access 2010 running on Windows 2008 Server 64Bit, while it works perfectly on a Windows Server 2003 machine 32bit with Access 2010 32bit.
I have a strange problem,
I have a WPF application. I have created a windows installer for this and installation will create application shortcut in user's start menu. I'm installing this MSI through windows service. Installation works fine through windows service but it doesnt create shortcut in start menu also i dont see this application under Programs and Features. But if i manually install this everything works fine. Any clue why this is happening ?
Code to execute MSI
Process installProcess = new Process();
//Assign required properties
installProcess.StartInfo.FileName = MSIEXEC;
installProcess.StartInfo.RedirectStandardError = true;
installProcess.StartInfo.UseShellExecute = false;
LogManager.Write("Process object is created");
//Create new StringBuilder instance
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.Append(SYMBOL_SLASH);
stringBuilder.Append(SYMBOL_INSTALL);
stringBuilder.Append(installerPath);
stringBuilder.Append(SYMBOL_QN);
LogManager.Write("StringBuilder is created: " + stringBuilder.ToString());
installProcess.StartInfo.Arguments = stringBuilder.ToString();
installProcess.Start();
InstallAllUsers property in for MSI was set to false. My windows service was running under Local System account and my machine was logged in with windows authentication under administrator account. So when the installation happened it was assumed that MSI is installed by the user other than who has logged into the machine with windows authentication so it didnt not show up in the start menu and under Programs and Features.
It was not necessary for me to keep the InstallAllUsers to false so simply i made it true which solved my problem.
I have a c# exe that calls System.Diagnostics.Process to run some commands in cmd.exe that installs a couple installers passively.. I've been testing it on my machine (64-bit win8 and it works just fine, but when I run the exe on a 32-bit version of Windows XP, the program simply skips over the process part. There are no errors thrown, it just ignores them. This is my code:
System.Diagnostics.ProcessStartInfo psi = new System.Diagnostics.ProcessStartInfo("CMD.exe", #"/C [command stuff]}");
psi.CreateNoWindow = true;
psi.UseShellExecute = false;
System.Diagnostics.Process diag = System.Diagnostics.Process.Start(psi);
diag.WaitForExit();
diag.Close();
What might be the deal here? Again I get no errors, it just ignores it. It's interesing because I can do all of that up there and just run date as the command and it works fine, but it won't run the msi and exe files needed to install. I can't find any information about it working in 64-bit but not 32. Thanks!
So I found out what my problem was. Before running the .msi to install, I changed directories using the syntax C:/folder/setup.msi. That works fine on my computer, but didn't do anything on the XP one. It turns out it didn't know how to handle the forward slashes. All I had to do was change it to C:\folder\setup.msi and it worked fine. I feel like an idiot, hope this helps someone though lol.
My C# programm starts java application on 64bit OS (Windows). Java process is 64bit, how can i fix my launching code to start java process in 32bit?
My launching code:
ProcessStartInfo info = new ProcessStartInfo();
info.WorkingDirectory = ServerProperties.ServerWorkingDirectory;
info.FileName = "java"
info.Arguments = "some arguements"
ServerProcess = new Process();
ServerProcess.StartInfo = info;
ServerProcess.Start();
Thanks!
This is more a function of the process you're starting as opposed to the process that's starting it (i.e. the process that you're starting has to have been compiled/targeted to x86 as opposed to x86-64).
However, if both x86 and x86-64 java.exe are installed on the machine-in-question, you can probably hunt the x86 one down by looking in Program Files (x86) as opposed to Program Files.
If you host your application in IIS you need enable x86 processes for pool of web app. Follows next steps:
Select the app pool for your web app.
Click Advanced Settings under Edit Application Pool on the right.
Change the value of Enable 32-Bit Applications to True.
Check next article for details - Support of 32-bit applications in the 64-bit Windows environment
I am trying in my application to launch Microsoft Excel with specific arguments (ie. additional xla & xll).
For now it works fine because all of my users only have Office11 (=2003) installed.
My company is going to switch to Windows 7 & Office 2010 and I logically can't launch any excel since the .exe is not located in C:\Program Files:\Microsoft Office\Office11\EXCEL.EXE
I ran a quick check in the registry to see that I can definitely check what version is currently installed. There are also plenty of articles explaining how to get the currently installed Office version.
However, I'd like to know if it is possible to find anything (such as a good registry key) directly giving me the .exe path so as to launch Excel.
Using my current machine (Win XP x86, Office11), I can find it in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Excel\InstallRoot
Using this key I can, basically, find a workaround to get the actual path. Problem: there is no such key in Windows 7's registry with Office 2010 (= Office 14) installed.
Do you guys know any way to launch the currently installed excel from C#?
FYI, here is the current code section, launching Office11 from a x64 / x86 machine:
private void LaunchExcel(string arguments)
{
if (!Is64BitsOS())
{
Process process = new Process();
process.StartInfo.FileName = "excel";
process.StartInfo.Arguments = arguments;
process.Start();
}
else
{
Process process = new Process();
process.StartInfo.FileName = "c:/Program Files (x86)/Microsoft Office/Office11/excel.exe";
process.StartInfo.UseShellExecute = false;
process.StartInfo.Arguments = arguments;
process.Start();
}
}
Any ideas to make this code more generic?
If you start Excel to open an Excel file, you can start a Process with the Excel file as FileName and let the Windows shell do all the work to find the associated application. You'd need an exception handler, obviously.
This would make you independent of Office and Windows versions and registry keys.
Otherwise you could take a different approach and find the associated application, like here.
The point of these suggestions is: presently, you have to change your code as soon as a new Office version is installed or a different Windows version is used, while there is a way to avoid these dependencies.
The 32 bit version of Excel 2010 running on a 64 bit version of Windows (XPx64,Vistax64,Win7x64) will have the following key.
I think this is the key you are looking for
HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Excel\InstallRoot
The 64 bit version of Excel 2010 running on a 64 bit version of Windows (XPx64,Vistax64,Win7x64) will have the following key
HKLM\SOFTWARE\Microsoft\Office\14.0\Excel\InstallRoot
copied from here