I am a non-professional who has a working Office Add-In written in VB for Visual Studio 10. It has no "written" problems.
I want to speed up the startup of the application because the Add-In seems to cause a 4-5 seconds delay.
I stumbled on this thing called COM SHIM WIZARD. Since this looks like a nightmare for a non-professional to implement, I want to ask:
1) Most sources I found were a little bit old. Is this something still used and usefull ? Some sources behave like it is a must for an Add-In, but it isn't for VS 2010 at least.
2) Will implementing COM SHIM WIZARD speed up my Add-In load if I manage to do it ?
I doubt that using custom com shim will speed up anything. VSTO provides it's own out of the box, so there is really no reason for custom one.
You may consider profiling your add-in to see what exactly is causing the delays.
May be simply using ngen.exe will solve your loading issue.
Related
I need your help in deciding the best strategy and technology to choose from for the continuing development of a successful in-house VBA application.
In our company (a web-based distributor of financial information), over the years, we have developed a VBA XLA Add-in application for use only inside our company, which helps in the linking of our database of financial information with Excel worksheets, through the use of several UDF's, supported by ADO/SQL and other business objects logic. This app became a solid, fast, and useful tool for us, somewhat similar to old DDE links, but much more sophisticated and flexible than that.
Recently we replaced the ADO/SQL portion of the system with a SOAP based Web-Service and XMLHTTP MSXML 6.0 technology, literally putting our database into the cloud. The goal was to transform the application into a product which could be used outside of our company. That work is already done, and its behaving quite well, with all functionality, load at startup, user authentication and session control login/logout, seamless integration with EXCEL, user-friendly messages, all done in a single 2.036Kb XLA Add-In file, spanning more than 15.000 lines of good VBA code. However, we feel that it cannot yet be distributed like it is...
We feel that in order to be successfully published as a product to our clients, this application must be transformed into compiled code instead of the interpreted VBA. There are many reasons to justify doing that, including security, speed, robustness, etc.. but we don't need to go into these details right now.
Our fist thought was to use VB6 and Automation Designers to quickly transform our VBA code into a VB6 Automation Add-in. Apart from the fact that VB6 is old technology, it seems that Automation Add-in's are not the ideal solution, for our app requires some interaction with Excel events and the End-User, at least during the "login" and "logout" into the web-service based database (and some other functionality that requires user interaction through forms), BUT is seems that Automation Add-ins are not suitable to anything other than UDF's only. Here we would like to learn about other's experiences with Automation Add-ins and end-user interaction.
So, COM Add-in's are the next option. Again, these allow interaction through menu buttons and commands, but do not allow UDF's in the worksheets. Or so we've read. Also, we have read that COM Add-ins can be made as Automation Add-ins (allowing UDF's after all), but that they will work as two separate entities inside the Excel environment (one COM and one Add-In), one half not communicating with the other. That's not acceptable to us. Again, we'd like to learn more about other's experiences in that regard.
Then there is Managed Code (.NET, Interop, and VSTO) as other viable options. However, while simple to get started with, it is not clear that Interop came to stay, and it is not clear what is the best strategy with managed code. Again, we'd like to learn about other's experiences in this realm.
So, the questions final is: given our requirements (i.e., load at startup, access to data through SOAP based web-service (MSXML 6.0), UDF's functions, login/logout session control, user-friendly error handling, etc.), and the fact that we already have 15.000 lines of good VBA code, which is the best technology for us to continue to develop this Excel component, in order to make it into an easily and safely distributable product? All comments and thoughts in that regard are very welcome.
I would take a look at Excel DNA: https://github.com/Excel-DNA
I had a very similar problem developing a VBA add-in that communicates with an ASP.Net Web API. Couldn't really give all the code out in VBA, so we needed a way of giving out compiled code. Connecting to the web service was freezing up excel making it harder for users working with massive spreadsheets with multiple API calls.
You can develop them in visual studios easily using VB so a lot of the code could just be copied and pasted over then changed slightly to fit the later version of VB you're using.
Add-ins compile to .xll 64-bit and 32-bit versions.
We handle all login and connection to the API in the Ribbon: https://exceldna.codeplex.com/wikipage?title=Ribbon%20Customization&referringTitle=Documentation
And you can use newer VB forms which are more user-friendly.
Connect to other .dll files for sharing logic across multiple add-ins.
The UDF we use which call the API can all run asynchronously freeing up Excels main thread.
https://exceldna.codeplex.com/wikipage?title=Asynchronous%20Functions&referringTitle=Documentation
It can run any VBA specific or CAPI code by queuing as a macro.
Pretty much do everything that you could do in VBA plus more.
Govert the Developer https://stackoverflow.com/users/44264/govert is very active on StackOverflow and forums. He's helped us out loads in the development. And Excel DNA is still being updated and worked on.
Let me know if you want some more details.
great summary of your project.
I'm also curious what other thinks about the "right" solution for such task. It won't be an easy decision though.
My short answer will be "stick with VBA" unless you are really concerned about stealing your code from the great VBA add-in.
The reason I'd go for VBA is that the longer I've been working with VSTO/COM the better I've found VBA to be the best for handling tasks that are closely related to Excel (understand MS Office) object model. I'm saying that even I have written almost zero lines of VBA code in last 4 years. I do understand that you are using webservices and other dependencies but I'd say that if you have good progress and the add-in is working as expected I'd NOT throw myself to a completely new world of development (VSTO & C#) just to be cool, you will gain not too much value of this, especially if you know that
deploying managed code is harder that just copy your add-in to a
folder, set registry, done
troubleshooting is a way harder with managed code, basically you will have to log much more and trying to reproduce issues that may not happen in your environment but happens in clients
re-engineering of managed code is not such hard so if people really wants to steal your code they can do that unless you use obfuscation
and the last and probably the most important for you as much as I'm aware there is no easy way to do UDFs in VSTO
I have very minimal experience with VB6/ COM Automation so I'd love to hear opinion of guys who have done something similar before
Re: the VSTO & UDF, at my job, we have a VSTO add-in that somehow handles UDFs for a large project. I'm not the main developer of the application but I believe we use Excel DNA there so do check it to explore the managed code option further
Hope that helps
The VS2013 XAMLX designer is very slow with medium sized xaml workflows.
About 10 to 40 seconds for each small change we make.
We don't want to disable the designer and work in xaml directly.
This is what we have done and tried so far (without success)
Disable Resharper
SSD Drive to speed up I.O.
Make sure the machine has enough memory and cpu...
Has anyone got more ideas on how to speed this up?
UPDATE (23-11)
This is a little convoluted, though it might shed some light.
I installed VS2015, which made a huge difference, though the workflows wouldnt work in IIS. The problem was due to a windows update which caused an error. Check this link https://support.microsoft.com/en-us/kb/3118750
I was getting errors like this:
FileLoadException: A procedure imported by 'Microsoft.VisualBasic.Activities.Compiler.dll' could not be loaded
So, I am guessing that validation was turned off while the compiler had issues.
It seems like VS2010 had a setting to turn off validation, though I cant find how to do that in 2013
Does this help at all, can anyone suggest a solution?
Background:
I have come up with an idea that will make things easier for the company I work for. They even seem excited about the idea. The idea is to make an addin for Outlook to help with a task. So after doing a bit of research (obviously, not enough). I downloaded a trial copy of VS2010 pro and created a VSTO addin.
After creating the addin, it was time to package it for a small test deployment. That's when I found out that this is a much more difficult thing to do. It seems MS does not ship Office 2010 with the runtime needed to run VSTO, so i'd have to package that as well. In a company environment, this is not something simple to do.
So, I might have to go back to the drawing board.
Meat of the question:
I've never created an addin for office before, I really want more of a "drop in" solution. I'm not sure if VBA is the right solution. It seems more of a "document" level application (or macro?). Does any one know what would be the best type of solution for this?
Outlook API is not native .NET framework. To interact it with, .NET relies on marshaling and interrop assembly thus making it much more prone to errors and unstable.
From what I've seen so far with my outlook API experience, I would stick with VBA and you should consider retrieving a third party library that exposes outlook extended MAPI if you run in to much of trouble.
NetOffice is pretty good - it is a set of managed .NET libraries that handles the COM API with Office and only needs XCopy installation.
The best part is it tracks all runtime callable wrappers ('RCWs') you create when accessing objects through COM and automatically releases them when you dispose the top-level object (the Application in most cases), so you won't get the issue of an orphaned COM 'handle' preventing you from closing Office.
Alternatively, the Office Primary Interop Assemblies should be on any computer that has the relevant version of Office installed (at least for >= Office 2007). But there are cases when it won't so you will have to cover that possibility. VSTO redistributable should already be installed on any computer with Office 2010 or 2013. For Office 2007 you will need to install it. But again, better safe than sorry so you should include it in your installer in both cases.
For details on deployment options look at http://msdn.microsoft.com/en-us/library/bb386179.aspx
As for VBA, I don't have experience for Outlook addins so I leave that to others to explain. Other VBA Office app addins (Excel/Word/Visio/PPT at least - not sure about the others as I haven't used them) can be installed either using registry keys or through XCopying the addin to a trusted location and then telling the user to open Options/Manage addins and tick the tick box.
I highly recommend Add-in Express. They have tools that go beyond what Microsoft provides via Visual Studio.
Their features for Outlook development greatly reduce the amount of effort required to build Outlook add-ins
We are in the process of creating active-x controls used within our application.
Since Microsoft stopped supporting classic Visual Basic, is it wise to use Visual Basic to develop the Active X control or the latest VC++/ATL/MFC libraries provide more feature where we can create controls faster by leaving Visual Basic flexibility?
We will not be able to use .NET/VB.NET/C# since the application is supposed to work inside containers and containers may not support latest .NET runtime.
Any other language is best fit for Active X control development other than VB and VC++?
I, personally, would recommend using Delphi for this. It is still actively developed, and has the control you get with C++, but a rapid development environment more like VB.NET.
#nobugz: If you are really interested what is ActiveX in Delphi, look at docwiki. Normally it is 100% source code (yours + VCL, VCL is also available as sources) with autogenerated COM wrappers. So all potential security problems are also in source code. If you find a security problem in VCL, please send a bug report to Quality Central.
Here is a good example on how to create ActiveX Controls with C# .NET
http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx
By all means VB6 is the best language. After reading your question I feel that you are a VB6 developer. If you know VB6 and use it then why hesitate using it for producing ActiveX controls.
I program in Delphi as well as VB6 along with VB.NET and C# but creating ActiveX controls is the easiest in VB6 compares to all other development tools.
If you are hell bent on not using VB and if you are looking for an alternative then try out PowerBasic (commercial - very costly) or PureBasic (commercial but affordable) Get it from here or better still MinGW (a GNU C++ compiler).
I have to say that VB6 with a good book like Developing COM/ActiveX Components with VB6: A Guide to the Perplexed you will be up and running faster.
Anyone know of a way to speed up the Visual Studio IDE when you have Telerik RadControls (either windows or web) and JetBrains ReSharper installed? If I disable ReSharper it runs rocking fast, but I love ReSharper a bit too much to drop it. I know it would perform better without the RadControls. Anyone know a way to speed it up?
I switched from DevExpress CodeRush/Refactor! to Resharper (not by choice) and found the IDE became almost unusable. I managed to persuade my boss to let me switch back (on my own personal licence) and now it's like walking back into the sunshine after months in a cold, damp cave.
I guess what I'm trying to say is that maybe you should consider switching to CodeRush and Refactor!
for me this is the same.
I'm Working with a Dell XPS 4gb Ram Quad Core Extreme Stripped disks...
And I also had that problem with telerik controls (mainly aspx - winform not so much).
Anyhow - I had to do a project using a different suite of web controls - and it was as bad as with telerik - or even worse...
What I found (maybe it helps a bit):
a.) Switching to design view slows down the things a lot
--so after doing this I restart VS
b.) Small Solutions (Projects) help also (like mika wrote) --if possible split your solution to several projects (some class libs instead of one big thing)
c.) Use as litte VS addins as possible --I used some nice tools - but at the moment most of them are turned of, because I made the expirience that the things are better the less addins I use.
d.) Run special "resharping sessions" -- what I mean is: turn resharper off, do you normal coding - and from time to time turn it on and "resharp" your code.
This problem (as well as some others) is well knwon (I guess) and I would say that neither resharper (although this tool seems to be somewhat special) nor telerik are gulty.
It is VS which makes the problems - and I did a lot of searches about solutions - but finally I found nothing which really helps.
Notice: I work on a pretty large project at the moment - and the use of respharper is almost impossible. I turned it off - instead I have a lot of nice snippets and macros which help me to do some of the common things.
Conclusion: if telerik + reshaper is to slow for you I guess you have to decide which helps you more :)
I use the telerik controls (ASPX, WPF and Silverlight) in almost every project I make. These tools fasten the things so much - I simply "need them to survive"
This is not much help, but at least the issue is not on your machine only...
Try to work with small solutions. In my machine this means solutions with less than 100k lines of code. Background compilation makes IDE sluggish with large solutions. VB has background compilation on by default, and even without add-ins it gets slower as the solution size grows.
I haven't been able to use ReSharper or CodeRush/Refactor! with VB & RadControls with over 100k line solutions, things just slow down too much. I'm using a Core 2 Duo, 2.4GHz, 4GB machine.
See also: Visual Studio performance and add-ins
Taken from Telerik`s forums:
We are incompatible with JetBrains Resharper indeed. We are competing for the same Visual Studio resources which could potentially create a ton of trouble if you run both of the add-ins together. I doubt that anybody managed to run them together but if you know somebody that did that I'd be really interested in all the details.
So you have to disable Resharper to check out on JustCode. You could always re-enable it later, however, as long as one of them is disabled they coexist happily.
Kind regards,
Tsviatko
the Telerik team
And I am pretty sure you will be way better using only JustCode