I have the following issue:
var oExcelApp = new Microsoft.Office.Interop.Excel.Application();
On this machine this starts Excel 2016, however I have both Excel 2010 and Excel 2016 installed on my machine. I'd like to start 2010 instead, and I'd like to keep both 2010 and 2016 installed on my machine when I do that.
According to this post, it's not possible. However, my understanding is that you can do this programmatically using the following commands:
(To register Excel 2010 as the default application)
"C:\Program Files (x86)\Microsoft Office\Office14\Excel.exe" /regserver
However when I run this command, all it does is open excel, the desired effect is not observed. Is there a way to do this, maybe with some sort of registry change? Or referencing a different version of libraries?
Update 1
I've tried this too:
var oExcelApp = (Microsoft.Office.Interop.Excel.Application)Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application.14"));
Doesn't seems to work either, disregards the excel version and runs 2016 irregardless of the specified version.
This seems to work quite well. Not sure what the difference between "_Application" and "Application" is, but per the comment "Application" is preferred:
string pathToTheVersionOfExcel "...";
int amountOfTimeToWaitForFailure = 5000;
Process process = new Process();
process.StartInfo.FileName = pathToTheVersionOfExcel;
process.Start();
Thread.Sleep(amountOfTimeToWaitForFailure);
oExcelApp = (Application)Marshal.GetActiveObject("Excel.Application");
Related
I used C# with a console program to create a new cmd process, did not redirect stdin or stdout, so I could type into the command line from here.
(I was having trouble using telnet from there, so this step was just an investigation.)
Able to type into the window and receive output.
When I switched to c:Windows\system32, typing dir te*.exe shows nothing.
In another command prompt I created directly, I see the file (telnet.exe).
Any suggestions about what is wrong?
{
ProcessStartInfo startInfo = new ProcessStartInfo(#"cmd.exe");
startInfo.UseShellExecute = false;
startInfo.CreateNoWindow = true;
startInfo.WindowStyle = ProcessWindowStyle.Normal;
startInfo.CreateNoWindow = false;
startInfo.Arguments = host;
using (Process p = new Process())
{
p.StartInfo = startInfo;
p.Start();
}
}
Since Windows 7, I believe, you have to install Telnet as a Windows Feature.
Here you have a guide to enable Telnet on Win 7, but it's applicable to Win 8.1 as well as Windows 10.
Just in case you can't read the site, the steps are:
Go to Control Panel -> Programs -> Turn Windows Features on or off -> Scroll down until you find the Telnet Client option
Based on the above article, looked at project build properties.
Platform target was set to x86.
Changing to "Any CPU" at least allows me to see the program!
BTW I have looked for the answer for several days before posting this, but in the margin in related - "C# New process created cannot access certain files" gave me the info - after I created this question
Thanks, heuristics!
This is a really devious one. When you are using windows explorer or opening a command prompt directly, you are starting a 64-bit process. When you are starting the "cmd.exe" with Process.Start(), you will get the same version as the process that's starting it. In your case, you are creating a 32-bit process, so you get the 32-bit version of the command prompt. If you change your project to create target x64, you will see the files!
Why is this so? Because, depending on whether you are accessing System32 through a 32-bit or 64-bit app, you will actually be accessing different System32 folders! For more on this, follow this link:
https://superuser.com/questions/330941/some-files-in-system32-not-accessible-outside-explorer-on-windows-7
I am trying to run EMC commands in C#. I am running this from my personal PC that has exchange management tools installed on it.
Our exchange servers have 2007 running on them.
The thing is, when I run Powershell or EMC, I need to run as a different user that has exchange server 2007 permissions since my individual profile doesn't have these permissions.
That being said, this is my code I have running on my personal PC:
RunspaceConfiguration config = RunspaceConfiguration.Create();
PSSnapInException snapEx = null;
PSSnapInInfo info = config.AddPSSnapIn("Microsoft.Exchange.Management.Powershell.Admin", out snapEx);
Runspace runspace = RunspaceFactory.CreateRunspace(config);
runspace.Open();
Command createCMD = new Command("Get-Mailbox ID");
Pipeline pipe = runspace.CreatePipeline();
pipe.Commands.Add(createCMD);
Collection<PSObject> results = pipe.Invoke();
The error I am getting is:
The Windows PowerShell snap-in Microsoft.Exchange.Management.Powershell.Admin is not installed on this computer.
I am getting it when I try and add the Microsoft.Exchange.Management.Powershell.Admin snapIn.
I feel this has something to do with my permissions on my individual profile, but I am not entirely sure. If it is true, how do I fix this.
EDIT
The reason I say it sounds like permissions is because I am able to open powershell and add the snapin. However when I run a command such as get-mailboxstatistics myUserId it throws an error saying MyServer\MyStorageGroup does not exist. However, when I shift-rightCLick and run as different user and use the credentials of my exchange admin account, I am able to run these commands.
If an error says it is not installed on your computer, why do you suspect it has something to do with permissions?
As this post suggests, please check if you have installed the 2007 version of the tools, as the Snapin in question is not available on the 2010 version.
Try the following steps:
Open up a powershell editor of your choice and add the PSSnapin there. If it works, the Snapin is available, if not, it is really not installed on your machine.
If it is available try to set your build configuration from x86 to 64bit or vice versa.
Eventually you can install the .dll in question by hand. Referring to this answer from Keith hill you have to issue the following Powershell commands
$snapinPath = 'Microsoft.Exchange.Management.PowerShell.Admin.dll'
C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i $snapinPath
Errors like this are often a 32 bit/64 bit problem. For example, the snapin might be registered as a 32 bit and your C# program is 64 bit or vice versa.
Sometimes you can fix this by running the other version of InstallUtil, e.g.
$snapinPath = 'Microsoft.Exchange.Management.PowerShell.Admin.dll'
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe /i $snapinPath
After fixing that, I think you'll hit another problem with how you're creating the command. You don't specify arguments when creating a command. Instead, you write something like:
Command createCMD = new Command("Get-Mailbox");
createCMD.Parameters.Add(null, "ID");
I have a problem with an MVC C# application in one controller.
The following code continues to give the error:
*The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.*
The code below:
var excel = new ExcelQueryFactory("~/App_Data/uploads/" + tempName);
var usersForImport = from c in excel.Worksheet<User>()
select c;
int count = usersForImport.Count();
for (int i = 0; i < count; i++)
{
User user = new User();
user = usersForImport.Skip(i).First();
db.Users.Add(user);
db.SaveChanges();
}
I have tried 2 solutions from previous posts, as I thought this problem was identical, but they do not solve the problem.
The two solutions I have tried are to install the Microsoft Access Database Engine or set the target platform for x86.
The code relies on 'linqtoexcel' package.
Has anyone else run into these problems? Any solutions?
For 64-bit apps, there are two versions of the ACE driver available:
http://www.microsoft.com/en-us/download/details.aspx?id=23734 for Office 2007
http://www.microsoft.com/en-us/download/details.aspx?id=13255 for Office 2010
I believe the Office 2007 version has the ProgId 'Microsoft.ACE.OLEDB.12.0', so I would try this one rather than Office 2010, which I believe has the ProgId 'Microsoft.ACE.OLEDB.14.0'.
From your description, it looks like the linqtoexcel package might depend on the Office 2007 version.
I have solved this in properties of the project, in the Build Tab.
I have changed the platform target from x64 to x86
I'm launching the path C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk via Process.Start, but it fails with The system cannot find the file specified.
The link shows up on a dir, so it exists.
Can it be permissions?
Notes:
The path is auto-discovered by iterating over the Start Menu directory.
I can launch it via explorer and command line.
Clarifications:
Code is as follows:
public void Execute() { Process.Start(_shortcut.FullName);}
_shortcut is of type FileInfo
_shortcut.Exists is true, so the file can be found
replacing _shortcut.FullName with the explicit path #"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk" has the same effect.
This is a WPF app using Caliburn and MEF.
Running as Administrator has the same effect.
This here on the other hand seems to work:
[Fact]
public void TestIisManager()
{
var path = new FileInfo(#"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk");
Process.Start(path.FullName);
}
It does seem to be a bit "environment" based.
Second clarification:
It seems to work in a Windows 7 x86 but not in a Windows 7 x64.
I ran into this recently. Windows Forms based solution, VS2013, x64 machine. Process.Start() could not launch applications via .lnk file. Using process explorer, it seemed that the target specified in the .lnk file was resolving incorrectly to c:\program files (x86)... instead of c:\program files... I followed Bruno's excellent advice, but then again my Target was already marked as "AnyCPU".
After some head scratching, it turned out there's a new compiler flag in VS11+ called "Prefer 32-bit" that was checked by default. This was forcing the EXE output to be 32-bit even though my OS was 64-bit and platform was set to AnyCPU. After I unchecked and recompiled, the problem was fixed.
More reading at: http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
Found the issue.
The WPF application was compiled as x86 (all other dlls were compiled as AnyCPU), and when launching some executables or links in a 64 bit machine it failed.
Changing the "Platform Target" to AnyCPU fixes this.
This may not actually relate to your situation, but you can launch the IIS Manager by using
Process.Start("inetmgr.exe")
If you want to continue to use the shortcut, it will probably work if you start the process using a ProcessStartInfo and set ProcessStartInfo.UseShellExecute to true
Can you make sure that you are trying this from an STA thread? You can see whether the apartment state is a problem if the following sample succeeds:
using System;
using System.Diagnostics;
public class Program
{
// make sure to call Process.Start from an STA thread
[STAThread]
static void Main(string[] args)
{
Process.Start(#"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk");
}
}
Process.Start calls ShellExecute under the hood to run the file passed. As described by Raymond Chen, shell functions require an STA thread:
One possible reason why ShellExecute returns SE_ERR_ACCESSDENIED and ShellExecuteEx returns ERROR_ACCESS_DENIED
As stated already, you will see the "The system cannot find the file specified" error because Windows is looking for inetmgr.exe in ...\SysWOW64\intsrv\ (caused by file system redirection), but it only exists in ...\System32\intsrv\.
This is caused by your 32-bit executable attempting to launch a 64-bit executable. As suggested, not using a 32-bit executable will solve this, but for anyone who must build for 32-bit (a WiX installer bundle in my case), try the following.
Using the start menu LNK/shortcut to inetmgr.exe instead of the executable is a good start, but an extra level of distance is required. This can be provided by using explorer.exe, which can be launched from a 32-bit executable:
System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
startInfo.FileName = "explorer.exe";
startInfo.Arguments = "/seperate /root,\"C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Administrative Tools\\IIS Manager.lnk\"";
System.Diagnostics.Process process = new System.Diagnostics.Process();
process.StartInfo = startInfo;
process.Start();
It's a bit of a hack, but try launching it like this:
string path = #"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk";
Process.Start("cmd.exe", String.Format("/k \"\"{0}\"\"",path));
Note the double quotes needed to save the spaces in the path.
That way, you might see a more precise error message and/or walk around in the command environment afterwards to see what is wrong with the path.
I have some trouble installing Management Studio 2008 Express through C#-Code.
The code looks like this:
using (Process MMSInstall = new Process())
{
var psi = new ProcessStartInfo(PathExe.FullName, "/qs /Features=SSMS /Action=Install");
MMSInstall.StartInfo = psi;
MMSInstall.Start();
MMSInstall.WaitForExit();
}
PathExe is a FileInfo-Instance.
But the installation always fails:
Exception type: Microsoft.SqlServer.Setup.Chainer.Workflow.NoopWorkflowException
Message:
No features were installed during the setup execution. The requested features may already be installed. Please review the summary.txt log for further details.
When installing via command prompt
C:\>SQLMANAGEMENTSTUDIO_X86_DEU.EXE /qs /Features=SSMS /Action=Install
everything works fine.
I looked through the logfiles (Detail.txt), and spottet a difference:
When running from the command prompt, 'Setting: MEDIALAYOUT' is set to 'Advanced' (pastebin.org/36222), when installing from my little C#-App it's set to 'Core' (pastebin.org/36221)
I tried to append /MEDIALAYOUT=Advanced to the ProcessStartInfo-Arguments in my code, but this options is ignored. I don't know what this parameter does, and I could not find any documentation about it.
Any ideas how to solve this or where to look for?
I am testing on Windows Vista Ultimate SP1
instead of calling the executable directly call %windir%\system32\cmd.exe
Cmd has a /C switch which allows you to pass in a command to run. So you'd pass in '/c "SQLMANAGEMENTSTUDIO_X86_DEU.EXE /qs /Features=SSMS /Action=Install"'
as a parameter.