I have an XBAP that needs to be able to burn cd's. When running from inside Visual Studio, everything works okay. However when running from a browser, the IMAPI dll reports that the environment is not supported as soon as it tries to access the drive.
I am assuming this is coming down to permissioning. I have a signed certificate which I have installed and the xbap is set to run as a full trust application (although I'm guessing that it can't be or I wouldn't be having this problem).
Currently this is all running on my local machine, however eventually I want this to be deployed to a web server (all users will already have the certificate installed on their clients).
Does anyone have any ideas as to what I've missed / done wrong?
Update:
I have tried creating a new, test certificate which I've installed in my certificate store and then signed the XBAP against it, but it makes no difference.
Really could do with some ideas if anyone has any?
Further Update:
I have created a console application which is able to burn cd's. Shelling out to this console application allows me to burn the cd from my xbap, but not from inside the xbap itself.
However, this is really not what I want. Ideally I want to have all this contained within the xbap. Failing that, is there a way to include the console application in the xbap's one click deployment?
Thanks
I believe this is not possible to do with XBAP. According to MS documentation on XBAPs,
Examples of permissions not available
in the Internet zone:
FileIOPermission - This permission controls the ability to read and write files on disk. Consequently, applications in the Internet zone cannot read files on the user's hard disk.
RegistryPermission - This permission controls the ability to read/write to the registry. Consequently, applications in the Internet zone cannot access or control state in the user's registry.
SecurityPermission.UnmanagedCode - This permission controls the ability to call native Win32 functions.
When you run your XBAP over the internet, you'll hit issue #3: trying to interop with unmanaged code.
I would recommend deploying your app as a stand-alone app with ClickOnce. That way, you can have full access to the system, but still get easy deployment and upgrades like you do with XBAP.
*edit*
One thing you could try -- and I can't guarantee it will work -- but you could have your users go into IE Internet Options, add your site to the trusted sites list. I'm betting then your CD burning code will work because it will be in the trusted zone, rather than the Internet Zone.
Try going to
HKLM\SOFTWARE\Microsoft.NETFramework\Windows Presentation Foundation\Hosting
in the registry
create a new DWORD named RunUnrestricted with value 1.
Related
I want to run an exe on client system from my c# asp.net website. When I use Process.Start()
it throws an error:
The requested operation requires elevation.
How do I set permissions to run that exe?
You can't spawn processes on the client machine from server-side code.
When you use Process.Start in server-side code, it is attempting to execute the process there, on the server where the website is hosted. If you wanted to create processes on the clients computer then you would need to expose a download for them (and not in employing subterfuge, like malign sites might do to install software - supply it gracefully, and normally (and with permission)), or a Silverlight application or something along those lines.
The bottom line is that the code you want to execute (even if that is just to spawn a process) must reside on the client, and be executed there.
You can't run an application from a web server like that. You will have to have the user download the application by supplying the EXE, a setup file or using ClickOnce.
Or you can develop an ActiveX control that you can have the browser automatically download from a Trusted Internet Zone.
Once downloaded, proper signing with a certificate (signed from the trusted (corporate) root certificate) will avoid the user getting a prompt to ask whether he wishes to allow the ActiveX control to install/be activated -
The ActiveX control can subsequently do anything the interactively logged on user could. This means that to actually install a program you'd need to elevate (UAC on Vista+); But if the goal was just to run a standalone executable, you should be good to go.
This all assumes white-hat purposes in a (larger) corporate setting, because it relies on PKI infrastructure and central browser policies, to name just two.**
This would, really, lead to some excellent questions on serverfault or superuser
I noticed you said you wanted to run an exe file on the client, but you didn't say explicitly that the exe is on the server and you want to push it to the client. Everyone seems to be assuming that is the case.
You CAN accomplish this fairly easily with a small JavaScript if you have a few prerequisites:
The executable is already present on the client machine.
All of your clients are running IE
You can enforce a policy to put your site in the Intranet or Trusted
Sites zone.
So basically this means it's a corporate intranet application. I am assuming this is probably the case since, well, if you were expecting to do this with a public app, I would be surprised.
For the script to accomplish this, please see my answer to this question:
How can I get a program on a client machine to run from an ASP.NET page?
Background:
I have a main application that needs to be able to go to the web and download DLL files associated with it (ones that we write, located on our server). It really needs to be able to download these DLL files to the application folder in "C:\Program Files\". In the past I have used System.Net.WebClient to download whatever files I wanted from the web.
The Issue
I have had a lot of trouble downloading data in the past and saving to files on a user's hard drive. I get many reports of users saying that this does not work and it is generally because of user rights issues in the program.
In the cases where it was an issue with program user rights every user could go to the exact file location on the web, download it, and then save it to the right place manually.
I want this to work like all the other programs I have seen download/install in this fassion (i.e. Firefox Pluign Updates, Flash Player, JAVA, Adobe Reader, etc). All of these work without a hitch.
The Question
Is there some code I need to use to give my downloader program special rights to the Program Files folder? Can I even do this? Is there a better class or library that I should use? Is there a different approach to downloading files I should take, such as using threads or something else to download data?
Any help here is appreciated. I want to try to stay away from third-party apps/libraries if at all possible, other than Microsoft of course, due to licensing issues, but still send any suggestions my way.
Again, other programs seem to have the rights issues and download capability figured out. I want this same capability.
The usual way to do this goes like this:
Your application detects that an update is needed.
Your application starts another (updater) application, that will download the required files and install them into Program Files. This updater application must run with administrative rights (i.e., prompt for UAC elevation in Vista/Win7). The easiest way to ensure this is to add an application manifest to that updater application.
If the user is an administrator with UAC enabled, point 2 will cause a UAC prompt to appear which must be accepted (note that the same is true for Firefox/Acrobat/etc. updaters). If the user is not an administrator, he will be asked for administrator credentials. (Note that this is a good thing: Only an administrator should be allowed to upgrade applications installed for all users.)
Your updater application does not need to be written in a special way: It can use System.Net.WebClient just like before. The application manifest will ensure that it requests the required premissions for writing to Program Files.
Note that this issue (Program Files not being writable by administrators without UAC elevation) is an operating system feature and not a programing language limitation, so you won't solve this issue just by "using a different library". If you want your application to run on Vista/Win7 and write to Program Files, you will need UAC elevation.
Check out the BITS service:
http://msdn.microsoft.com/en-us/magazine/cc188766.aspx
Writing to the Program Files directory requires UAC elevation (if the user has that enabled) on Vista/Win7. See this code sample on how to prompt users for permission: http://msdn.microsoft.com/en-us/library/aa970890.aspx
Really though, please think about designing your app so that it writes to a more appropriate place where this is no risk of accidentally overwritting a critical program file.
How about trying http://netsparkle.codeplex.com/. A port of the very successful Mac Sparkle framework http://sparkle.andymatuschak.org/.
Does it really need to be in Program Files? I had a similar problem in an application, and we've written a class to resolve non-installed assemblies by first trying to load them from a subfolder of the %usersprofile%, then by going trying to download. This can be seamless if you add you resolve method to the current app domain's AssemblyResolve event.
AppDomain.CurrentDomain.AssemblyResolve+= AssemblyResolve;
public Assembly AssemblyResolve(object sender, ResolveEventArgs args)
{
//try to get locally
//try to download
return assembly;
}
Don't do it.
Theoretically it can be done easily. you just lunch another app, that runs with administrative privileges - you can request these in configuration. In the updater app, you just connect to a secure(ssl) web site, download everything you need, the files you download must be cryptographically signed.
This can also be easily solved using ClickOnce or some other web installer, capable of updates.
What you shouldn't do is just download insecure DLL's from an unverified source and execute them.
I wrote a C# application that is running well on my xp development machine.
When my client is running it on different PC, it seems to freeze on both vista and 7 machines.
I would like to know if there is any issue on running dotnet applications on vista/7.
I compiled the application for both framework 2.0 and 3.5 but it didn't help.
The log file neither doesn't help.
Is there any way to know where is the application freezing (of course, the client doesn't have VS for attaching to the application) ?
Thank you in advance for any help.
Pierre.
Generally, .NET application should run the same on any Windows version with .NET framework installed. Most common problem that occur are related to the new User Account Control policy in Vista and 7, which prevents applications from accessing areas requiring elevated privileges (which would otherwise run fine under an Administrator account in XP).
For example, if your application is trying to write configuration settings to the Program Files folder (which is a really bad idea, btw), or is using some hardcoded disk or registry paths instead of environment variables provided in .NET classes, it may fail under Vista.
To quickly check if this is an UAC privilege problem, try to run the application as an administrator (have your client right click the .exe file and select Run as Administrator). If it works, then this suggests that you need to examine your code and update it to make sure you are only accessing allowed areas.
Check this link for more information: Making apps UAC aware.
As redsquare suggested, the best way to test your application in a variety of Windows systems is to run them in several virtual machines (MS Virtual PC or VMWare Player, both of them free for download).
You do not give much information in order for us to help a great deal.
I would start by trying to recreate the issue locally on a virtual machine (vista one available here) and then profiling the app with something like memprofiler.
Ask your client to capture a process dump using Windows Task Manager,
In Task Manager, find the process that hangs.
Right click and capture a memory dump.
Then you can do some analysis on the dump to see why it hangs.
If you are not familiar with dump analysis, find someone who can help or open a support case via http://support.microsoft.com
csharp applications are supposed to run on vista/win7. This is their home:)
Your problem is not the OS. its your application.
Most probably the application is looking for a file, a folder, something on the client side that is not there and its freezing. this is my experience.
Check for project independencies and make sure you have shipped to your clients everything your project needs.
and last, distribute to one client the debug version with debug messages enable and get the feedback from their system.
I've got an app that publishes and updates from an http update location (I publish to the ftp site of the host, and update from the website).
The publish.htm page is very handy as I can install the app on any machine, anywhere without needing media. The problem is, so can anyone else. How can I secure the update location so that only authorized users can install the app without buggering the auto-update feature of clickonce?
Is this an internal application? If so you could just exclude the publish.htm page from your deployment. Then to install you would then just use the application manifest link http://yoursite/YourApplication.application which should kick the install off, this would not affect automatic updates. This may be just enough obfuscation to for your purposes.
Failing that you can dynamically generate the application manifest using a little bit of asp.net which would only produce the manifest for the users you want. The other benefit this has is that you can isolate a small group of users when rolling out a new version.
Just a thought.
If you're still transferring over HTTP, it's as easy as running a traffic sniffing program like Wireshark to see where the application is downloading from. To evade this you'll need to make sure to transfer over HTTPS, on top of whatever obfuscation you do to hide the update location.
Does anyone know how to get the MS Office 2007 .NET C# Interop libraries to work with Vista?
I have a .NET C# application that I have setup to run as a Windows service. This program will open up a Word or Excel template depending on the situation and modify its contents and then save the document back out. All of this worked great when I was doing it on a Windows Server 2003 or XP machine using Office 2007. When I moved everything to a Server 2008 box, everything quit working. In Excel for example, I get a COM exception telling me that the Excel file cannot be opened when the file is clearly there and I can open it just fine when doing it manually. The windows service is running under the same user account that I log into the machine with and that account is an Administrator.
Does anyone have any idea what to do?
On Vista and Windows Server 2008, services run in something called Session0. Before Vista, regular programs would run in Session0 alongside services.
This means that Session0 has become a desktop-less wasteland where your services can't even access explorer.exe. I'm pretty sure the problem is that Office applications are expecting to be able to access a few components that are normally on the desktop.
Since Excel, Word, etc. are only supported on a desktop-ed session, you only have a few choices:
Set the Desktop checkbox in the LogOn tab of your Service's properties and pray that it appeases the Office gods. (It probably wont.)
After trying 1, go through your code and try and remove/work around anything that causes it to crash.
Use remoting/WCF to make a server that performs the interop work, and make your service communicate with it.
You'll need to have a logged in interactive user and the user needs to start the server application somehow. Perhaps best to use autostart.
You can try turning on Automatic login. http://support.microsoft.com/kb/324737
Try impersonating a Logged in user using CreateProcessAsUser and friends.
Note: I don't know how well this works unless a user is actually logged in, so it might not be any more useful than 2 above, and is much harder to pull off. (Needs P/Invoke)
Rewrite your program to use the OpenXML sdk or use something like SpreadsheetGear.
You should really avoiding running the Office clients as server side apps. Consider using xml as file format (xlsx for Office 2007, or using the Excel workbook xsd for (somewhat) older versions.) Then you would be freed from using the Excel API on the server.
I did find an interesting article from Microsoft basically saying don't do Office automation.
Get the installables from
http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en
install it on your system and refer excel dll in your solution and hopefully it should work.
Do you have the primary interop assemblies installed on the server? These are usually located in the GAC and not included in the bin directory when you build your program, so they would need to be installed locally on the server.
This is just a guess, but it might be UAC. I know that privileged (admin) applications and user applications cannot send messages to each other or communicate in any way. Your service is running as an administrator, but your desktop is running as a regular user under UAC even though they are the same user. I also expect that Office has started up (pre-loaded) parts of itself on startup and that would be running as a regular user.
Try turning off UAC and see if that helps. If so, at least you know what it is.
Do you leave an account logged on to the machine? Office is not a server-side app, and you will get random errors if you try to launch any of the executables without a desktop context.
Something to remember about Office. Its x86 only, so if your creating an application in x64, you will not be able to access the Office underlying COM objects. You will need to compile your application in x86, then it would work.
You can do that by going into the properties of your project, and selecting x86 under the build tab in visual studio.
This is all assuming that your app is being developed/run in a x64 enviroment that is.