I'm analyzing malicious document and started locking in Process monitor. I see lots of windows events working in background. can someone explain how macros process
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
To nip this in the bud, I have posted this question and workaround. I would like to accept an answer that actually quantitatively describes the problem.
I do some office programming using VS2010 and VB.NET. I have found that using VB.NET over VBA provides a much better user experience for office automation tasks. But, VB.NET IDE sometimes, not all the time, grinds to a halt when debugging Excel COM interop code, such as it takes 5 minutes to set a string equal to the value of cell, or just removing and adding breakpoints takes minutes apiece. This has been the bane of my existence for sometime, as I would have to restart my computer to fix it, but I have finally figured out the causal actions and a workaround. It happens when I have more than one other Excel instance open besides the COM server. I know Excel usually only opens one EXCEL.EXE, but, I have my registry settings so that every excel document opens in a new instance, so that I can look at separate docs on separate monitors. I don't believe this is uncommon. So, when I have left Excels open and my app starts an Excel COM server and breaks into the debugger, this is when the problem occurs, but also only if I click or operate in someway in one of the Excels after starting the COM server. Then it is like the COM server gets confused as a chameleon in a bag of Skittles of which it can't get out until I restart the computer. So, does anyone have enough debugging, COM, and Interop expertise to tell me what is causing this debugging hell? And possibly a way to preempt it?
To workaround this problem without restarting, I have found that I can end all instances of EXCEL.EXE, even the COM server, and close the IDE, then reopen Excel directly without a document and close it. Now, reopen the IDE, run code, start debugging, and stepping latency is non-existent or negligible.
I am studying Visual Basic .NET
I would like to know that finishing application on the form without closing form.
For example, I am running task(without using thread) on the form.
When I click "stop" button, i would like to finish (like go to the end of program) without closing form.
I tried disposing or application.close. It was stopping and go to the end of the code. However, it was closing the form.
is there anyway that just finish task and keeping the form ?
Please read BackgroundWorker Class Sample for Beginners.
Designing applications that block the UI thread and then hope to be able to react to events during potential idle times is asking for trouble. Your UI will never be fully responsive and it will be a nightmare for anyone else to maintain and/or debug. The UI thread is intended to do one thing, interact with the UI. Long-running tasks are meant to be run on background threads and potentially split across multiple threads and/or cores.
I need to create a Custom business card along with custom form , and I want to send it as an attachment just like a normal business card , but receiver should be able to open it with the custom form.
You have a VBA tag but there is no VBA solution. You cannot send live VBA to others. They would not thank you if you figured out how to do so.
http://office.microsoft.com/en-001/outlook-help/how-outlook-helps-protect-you-from-viruses-spam-and-phishing-HA010355583.aspx
Protection from macro viruses
The purpose of a macro is to automate frequently used tasks. Although some macros are simply a recording of your keystrokes or mouse clicks, more powerful VBA macros are authored by developers who use code that can run many commands on your computer. For this reason, VBA macros pose a potential security risk because a hacker can introduce a malicious macro through a document that, if opened, allows the macro to run and potentially spread a virus on your computer.
In Microsoft Office 2010, the Trust Center helps to provide protection against potentially unsafe macros. In addition, Outlook blocks many potentially harmful attachments.
In any case, if answerable, it is a SuperUser question. https://superuser.com/
I may be the only person still automating excel this way and I am looking at doing it in ways that better handle COM objects and such, but for now I just import Microsoft.Office.Interop.Excel and go for it. Something that gave me a lot of grief at first was hanging excel.exe processes, but there are tons of resources online for fixing that. At this point I am pretty confident in my abilities to handle it.
One thing I did notice and was wondering about is how does closing a windows forms application interact with excel.exe running in the background and likely more specifically the garbage collector. I have written quite a few excel automation projects and noticed that after I run my program .exe and it has completed there is an excel.exe process that hangs on until I close the pop up window from the windows forms application. Why is that happening?
Does vb.net not call garbage collect until after the window is closed? Looking at the code I write there is no reference to an "on close of application window" event and the garbage collector and release COM objects calls are all right in the code, so it seems curious to me that after the code has executed (which I take to mean garbage collect has been called, as in the code) there is an excel.exe process that stays up until I actually close the windows form application window.
Nothing urgent, more curiosity than anything, but any direct would be appreciated. Thanks.
Make sure you are calling the Quit method on the excel object at the end of your code block and you can garbage collect for good measure but it should close in a short while. I had the same problem but found I had to dispose manually.