Our Excel 2007 VSTO solution (built in Visual Studio 2010 SP1 using C# 3.5) is published via ClickOnce.
Clients deploy by clicking a URL using Internet Explorer that looks something like:
http://ourserver.com/ouraddin.vsto
It sometimes causes the Program Compatibility Wizard to pop up post-install and display "This program might not have installed correctly ..."
Does anybody know any workarounds?
I found this post which talks about modifying the manifest files, but that seems to apply to regular ClickOnce solutions not VSTO.
How to prevent "This program might not have installed correctly" messages on Vista
I tried using the MageUI app to open the VSTO file and look for a way to embed the supportedOS tags but there was nowhere to put it.
I also found documentation on editing VSTO manifests, but would prefer not going down this route unless absolutely necessary as one would think the publish wizard out of the box should just work.
http://codeidol.com/csharp/c-sharp-in-office/Deployment/Editing-Manifests/
Perhaps there is a way to modify the source VSTO ClickOnce schemas in the build system to avoid editing the manifests as a post-build task?
Any insight would be greatly appreciated!
Thanks,
Chris
Related
Visual Studio has a template for a Word web add-in. Clicking 'Start' opens Word with the add-in loaded, and allows for immediate debugging of the front-end javascript in the IDE.
Word was running the add-in in ie11.
With this project, the only options I've found are debugging with 'f12' debugger located in C:\Windows\SysWOW64\F12\IEChooser.exe (or System32).
I installed the latest version of windows to get access to the new Windows Terminal. This update also switched the Word add-in to load in edge instead of ie11, which requires the new Microsoft Edge Developer Tools.
I would like to get access to the functionality Visual Studio provides for debugging front-end code via an IDE instead of f12/edge developer tools. I cannot find out how Visual Studio allows this debugging as all of the properties are hidden away as settings in .sln and web.config etc.
Is there any way to debug this add-in with Visual Studio/vscode (preferrably vscode)?
There are many ways you can use VSCode for debugging but all debugging methods depends on external browsers like chrome, IE, edge debugger. I believe you do not want to perform this in VSCode.
This method will help you in some way. But I am sure you can manage this.
Step 1. Create a word web addin using Yeoman generator. Official link below
https://learn.microsoft.com/en-us/office/dev/add-ins/quickstarts/word-quickstart?tabs=yeomangenerator
They use nodejs and you can choose Angular / React / JS to build your addin.
The advantage is it will give you the flexibility to debug in any IDE .
Caveat: As I said above you can easily build the Addin with the help of web technology.
Step 2: Debugging: either you can use VSCODE Debugging functionality or use the browser
Step 3: If you choose browser: Go to sources > Choose Webpack > Select the .ts or /js file and set the breakpoint. Screenshot below for your kind reference.
note: I have selected Angular from office generator to build the addin. Then you can see the webpack under the sources. I believe this is the same for any technology.
Hope this will help you.
I have a Windows Form application that deploys using Microsoft Click-Once. I would like to add a new feature to the application that in part utilizes a third-party DLL that happens to be obfuscated. During an initial test release of the application, the application wouldn't install. Initial research seems to indicate that Microsoft Click-Once and Obfuscated DLLs don't play well together. Is that the case? If not, is there a special way to get an Obfuscated DLL to install/work in a Microsoft Click-Once deployment?
Thanks!
I've successfully created a VSTO Add-In for Outlook 2007 in VS2010, yay! Now comes the deployment part, which seems to be even more arcane.
I need to deploy this Add-In on my company's server, which is running Windows Server Standard, SP2. It has MS Office 2007 on it, and the clients talk to a different Exchange server. The company has thin clients that all Remote-Desktop the Server to access their Outlook.
What would be the procedure for this? There's various articles that Google pulls up on deploying Office Add-Ins, all of which are a tad over my head. My impression is that there are many different ways to install Add-Ins, based on what Office version you have, what VS version you have, what OS you are installing it on, if you want to install for a single user or all users on the server, and various other circumstances. I can't get a clear picture of what to do. The fact that I'm installing on a system with a server/thin-client arrangement possibly complicates things.
Anyway, I can spend the next few days researching how registry keys work and how they affect Add-Ins, learning how to make .MSI packages, exactly how certificates work and if I need one to publish or if I can deploy into the Program Files directory, or if that option in the .NET 4.0 framework even applies to a VSTO Add-In, etc., etc., etc.
There's just a lot of variables and I would appreciate advice that pertains to my exact scenario. Or, barring that, exactly what subjects I need to study up on to know what to do, and links to them.
Edit: I need to deploy to 1 user on the server first, for testing, and then eventually all or most of the users, so help for singular and broad deployment would be appreciated.
The following articles helped me a lot when I first tried to deploy an add-in. Unfortunately my scenario did not included server/thin-clients, I used the MSI only for per-user installations, so I cannot say for sure what will be the complicates to rise from the side.
Here is the article:
http://msdn.microsoft.com/en-us/vsto/ff937654.aspx
There you should find all the info required for registry location, files, manifests, etc...
I'm undecided about CRM at the moment. It's a great tool for the business users but so far for development it's been a bit against the grain. The next problem I need to tackle is how to easily source control javascript used within forms. We use TFS for our source control.
Anyone had an experience or have any ideas on how to do this?
Obvious choice would be to copy and paste the JS in to your source control, but it's also an obvious pain in the rear.
A couple of things that we do in our projects:
We use the Web Resource Utility included with the CRM SDK (actually a modified version of it) to deploy JavaScript web resources to a particular solution. Makes it very easy to keep script files checked in to source control as normal and avoid copying and pasting.
We wrote a custom HTTP Module that we use on local deployments. It intercepts requests for JavaScript libraries and redirects them to a location on local disk. That way, we don't have to actually redeploy the web resources as we test, just the JavaScript files to disk. (Note that this would be unsupported in a production environment. We just do it in our development environments to ease the pain of JavaScript deployment).
I answered a very similar question here - Version Control for Visual Studio projects and MS Dynamics CRM (javascript)
My choice for source control is TFS holding each of the 2011 JScript libraries.
We try to mirror the file structure that Dynamics uses for Web resources in a basic Library project. So version control works as normal, we just don't use the output from the project.
You can also try using the new "CRM Solution" project template (installed from the SDK) and have the ability to deploy from the context menu of the project.
I've had some issues with the template but something to check out.
Hope this helps.
You can take a look on my answer on my own question here.
MS Dynamics CRM 2011 SDK has solutionpackager.exe utility what could split all CRM resources into file tree and you can store them either in git or in tfs.
Any web resource in CRM 2011 is a pain to manage. We just end up doing a lot of copy pasting in and out of TFS 2010 (which has actually caused some problems with poor pastes).
Currently out of the box there isn't an easy way to do it.
Only worry about this if you really need the ability to go back to old versions of web resources. I've found that I don't often have to do this. Remember that the web resources are stored in SQL Server just like they would be if you put them in TFS, so as long as your CRM database is being backed up, you won't lose the web resources. In traditional development, it is important to keep the source in TFS because you can't easily get back to it once you compile and release. With CRM development, your web resources are mostly HTML or JavaScript, so you can always get at the source.
If you really need version control, why not build a quick little console app that downloads all customizations every night and stores that zip file in TFS? True, it wouldn't be as easy to get at older versions, but you should gain a lot of productivity by not having to manually keep TFS in sync. This also has the benefit of storing all customizations in TFS, not just web resources.
Silverlight is the obvious exception here - I would definitely store Silverlight web resource source code in TFS, because it is a "compiled" web resource. You are already in Visual Studio, so TFS is a natural fit anyway.
Hope that helps!
I'm working on some legacy code for a client, involving Microsoft Content Management System (MCMS).
Currently, everything is local, the code, MCMS, SQLServer, and IIS (5.x).
I copied the project folder, and then opened the new copied solution in VS2005, and let it do it's conversion thing.
But now nothing works. I've nnotice there have been some changes to IIS profile. What are the extent of these changes...??
Also, my VS2003 fails to recognize the Web Project??
Anyone have any idea what's going on?
cheers!
Not really sure the extent to which MCMS affects anything (since I have not used that tool) but as to the question on the VS2003 not recognizing the web project, the issue is that when Visual Studio 2005 does it's upgrade, it changes the format of the VS2003 project files to VS2005 format. This means that once you have upgraded a project to VS2005 you can't go back and open it using VS 2003.
As far as changes to the web project go -
VS 2005 by default completely changes the layout and mode of your web projects. If you want to retain the familiar (and IMO better) web application layout from VS 2003 you need to use the web application project option which is available as a download - details are here
Hope this helps.