We have created a VSTO Plugin for Outlook. Is it possible to make Outlook look a directory outside of C:\Program Files for the location of plugins?
Outlook can look at any directory you choose (local path, UNC, or HTTP) - which you define in your Manifest registry key. The issue you will have is that installing outside of the Program Files directory will require you to have a Trusted Publisher Certificate or an Inclusion List - another hoop to jump through.
The reasoning is that you need administrative permissions to install to Program Files, so Outlook automatically trusts any plugins with their manifest pointing to the Program Files path.
Related
I have written a Visual Basic.Net application in Visual Studio 2012 Ultimate. When this application is installed to the Program Files folder, when files are saved, they are located in this location:
C:\Users\[Username]\AppData\Local\VirtualStore\Program Files\[Company Name]\\[Application Name]
How can I specify to save the files in the following directory:
C:\Users\[Username]\AppData\[Company Name]\\[Application Name]
folder (basically, not the VirtualStore folder)?
Do I need to register this application within Windows to do this?
Thanks in advance
First, what instalation software are you using?
Second, if you're going to save your app files in the AppData directory, then you should really choose to save your app in either the, Roaming, Local, or LowLocal directory. It isn't "proper" to start making new directories where other directories are available to use, especially since the Roaming, Local, and LowLocal directories were more-or-less made to hold application's data (which is why the parent directory is call "AppData").
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
We have an installer for our application that must be downloaded and run with administrator privileges, like many other installers. However, the installer isn't named "setup.exe", so Windows doesn't automatically detect it as requiring elevation to run.
Changing the installer name to make things elevate properly sounds pretty messy, frankly. This article talks a lot about UAC and elevation, and it says that you can use a manifest to make something require authorization.
So, we'd just love to create a manifest for our installer. However, how do we ensure the manifest is present? If the user just downloads our_application_v13.exe, how do we ensure they get the manifest too? AFAIK the manifest would have to be a file named "our_application_v13.exe.manifest" in that case.
Since they're just downloading a file from our web site, how do we make sure they get the manifest too? Can we build it into the executable in some way, or otherwise flag the executable as requiring elevation? We are using an installer tool from hundreds of years ago that we can't change, so it doesn't have any capabilities relevant to this.
Thanks!
If the installer tool allows you to change/attach/edit the resources of the generated EXE file, you can add the manifest file as a resource with a resource type of 24 (RT_MANIFEST in the windows headers) and a resource id of 1.
If The installer tool does not have the built in facility to insert resources, then you might have to write a tool to post-process your install.exe file to insert the resource. Look up the Windows APIs BeginUpdateResouce and EndUpdateResource. They have some limitations - they tend not to work if the EXE doesn't already contain any resource files at all, but most install tool generated exe files contain at least a version info resource.
Also, if the install is digitally signed that will have to be done after insertion of the manifest resource.
Also, mt.exe included with the Platform SDK and most versions of visual studio has options to embed, extract and merge manifest resources.
The manifest can also be in the application's native resource section (inside the EXE).
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate post-processing of your install exe file and insert the manifest resource. See specifically the Adding Application Manifest page for greater details:
http://www.heaventools.com/rtconsole-embed-manifest.htm
When I deploy applications to our BizTalk server, we deploy to a test machine, add all the necessary resources and then export an MSI that we import on our production servers (we have two). The other day I noticed that there are dozens of folders on our production servers that appear to be copies of each developer's source code location.
For example:
C:\Development\MyProject1
C:\Projects\SomeProject
C:\Users\Ryan\My Documents\Visual Studio Projects\Another Project
Many others
They're all projects we've deployed to BizTalk and the folders don't contain source code, just the "Deployment" folder of each BizTalk project with DLL files in it. However, I thought the MSI packages were adding the DLL files to the GAC, or at the very least, were putting them in the MSI install target folder (all MSI files are installed to "C:\Biztalk\ProjectName").
Can somebody shed some light here? Are these extra copies safe to delete, and will that stop my BizTalk applications in their tracks?
(I just reread your question and see that my answer may need some more context. Before you deploy the next time, have the developers follow the steps below so that you won't end up with the folders you mentioned in your question.)
You have control over the installation folder - you just need to change your resources' destination using BizTalk Administrator. You can also control installation in the GAC.
Use the following steps to modify the installation folder (things get installed in the folder that the user specifies when running the MSI):
In BizTalk Administrator, under your Application's Resources folder, review the values under the Source and Destination Location columns - you'll see folders and drive letters that exist on your system.
For each item in the list, right-click and select Modify
Change the Destination location - the path part of the location - to **%BTAD\_InstallDir%** (include the % symbols and separate the last % from the file name (probably a DLL) with a back-slash character ( \ ). So, it might look similar to this when you are finished: **%BTAD\_InstallDir%**\MyStuff.DLL
Export your application
Run the MSI on your target systems - things get installed in the folder that the user specifies when running the MSI
This is the essence of the solution - I coincidentally wrote a brief blog post about this last month.
I wouldn't delete them until you did a redeployment. BizTalk is remembering the location the resource was initially added to the resource meta data source. For purpose of generating an MSI you should add the resources from where you want them to reside on the production server.
If I use the publish feature in VS2008 (I think it's called ClickOnce install), and then install the published application in another computer, where are the files copied?
In other words: If I need an auxiliary file (a .txt file) in the same path of the assembly, where do I have to create it?
Thank you.
You should have specified the location when you published the application. Just note down that folder.
If you run the wizard again for the same project it should have remembered the location and the folder will be pre-filled on the form.
I've used this and I specified a location on my hard drive for the Publishing Folder Location. This folder contains the following files:
publish.htm
setup.exe
[application].application
It also contains a folder called Application Files which contains the files needed to build the installation - the exe, the manifest, other dlls and external resources.
I then copy the three files and the folder to the web location specified by the Installation Folder URL.
If you're talking about where the files get installed to then they're in:
C:\Documents and Settings\[user]\Local Settings\Apps\2.0\H165QZM1.QBE\0OAEZTRX.Y3N\[some truncated version of the exe name followed by a GUID]
Which isn't the most obvious place. I should also point out that the folders H165QZM1.QBE and 0OAEZTRX.Y3N will probably be different on different machines, but the only other folder under C:\Documents and Settings\[user]\Local Settings\Apps\2.0 is called Data so they should be easy to spot.
Is the application available offline or online only? My experience is online only and in that case I believe it installs into a temp directory. Can you include your auxiliary file as part of the application files? This may help as well it talks about including data files which can be of any type.
http://msdn.microsoft.com/en-us/library/d8saf4wy.aspx
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx