My impression is that standard Delphi uses the Win32 API.
Recently Microsoft has been communicating a problem regarding ATL that requires application developers to rebuild ATL-using applications after installing an update on their machines.
Will this practice be the general case also for Delphi developers, or are they in the clear with the exception of Delphi code using third party ATL COM objects?
Sources:
Microsoft Security: Protect your computer from the Active Template Library (ATL) security vulnerability
MSDN VC++ DevCenter: Active Template Library Security Update for Developers
Microsoft Security Advisory (973882): Vulnerabilities in Microsoft Active Template Library (ATL) Could Allow Remote Code Execution
Microsoft Security Bulletin MS09-034 - Critical: Cumulative Security Update for Internet Explorer (972260)
Microsoft Security Bulletin MS09-035 - Moderate: Vulnerabilities in Visual Studio Active Template Library Could Allow Remote Code Execution (969706)
The ATL is a template library for C++ code, and so it has nothing to do with Delphi. If you're using 3rd party ATL COM objects, then yes, those will have to be rebuilt, but your Object Pascal code is safe.
This was mostly caused by unsafe string handling routings in ATL - thankfully string handling in Delphi is completely different and separate. No need to worry.
Related
Is there a MSAL/ADAL equivalent for C++ ? I would like to natively support getting access tokens for Azure in C++ (rather than build a bridge of some kind by using python version.)
Thank you
I am the current contact at Microsoft for both MSAL or ADAL C++.
Microsoft has MSAL C++ in development and it will eventually be open source. Its code is used in major products made my Microsoft.
ADAL C++ is not released externally and is not open source.
Our guidance is to interop with Python or .NET at this time.
There actually is a C++ ADAL SDK, Microsoft releases it to partners and uses it internally.
It is not generally available, but if your company has a liaison with Microsoft, you can ask for it.
When building any addin (in Visual Studio) for Microsoft Office, we have to choose the target .NET FRAMEWORK.
Actually, on several PCs, where I've installed MS OFFICE 2010 it required neither .NET 3.5 nor 4.5. However, while trying to install my add-in on that same PC, it requests .NET.
Is it not possible to make the addin to work like MS-OFFICE works (without requesting the .NET framework) ?
To answer the stated question:
How does Microsoft Office doesn't require .NET 3.5 or 4.5, while VSTO
addins require them?
Microsoft Office is COM-based and written using C-languages (C, C+, C++, but not C#), so the .NET Framework is not required. Office pre-dates .NET by more than a decade!
If you develop an Add-in using Visual Studio .NET then it will require the version of the .NET Framework selected for the .NET project to be installed on the machine. This is the case with VSTO, for example.
Classic VB6 used to be a common tool for creating Office Add-ins. It didn't require .NET because it was a COM programming language - and that's why it wasn't maintained or updated so that its programs could run on more recent versions of Windows (64-bit). So it's fallen into disuse.
Any programming language that can leverage the IDTExtesibility2 Interface that builds the basis of Office COM Add-ins can (in theory, at least) be used to write a COM Add-in for Office. It's necessary to research and understand that Interface, as well as how the chosen programming language relates to the Windows COM environment, in order to program an Office Add-in.
Microsoft Add-ins of the type you're thinking about canNOT be developed using VBA (as has been suggested in a comment) - VBA must run in a host application and is contained in a document belonging to the host application. VBA is able to automate other Office applications, but this does not qualify as an Add-in. In most Office applications VBA can be used as an "add-in" for that application by loading the code-container document in a certain manner, making the code available to all files opened in the Office application.
Recently Microsoft introduced the Office Add-ins architecture which allows for developing add-ins hosted remotely and run within IFrames inside office. I have read a lot trying to understand whether this architecture is meant as a replacement for VSTO or do they have separate use-cases. VS 2015 has templates for both.
In my specific case, I want to develop an add-in that extends Excel 2016 with custom import functionality (e.g. custom CSVs, TSV, or even XLSX). I can't tell which type of project I should go with.
Given the amount of legacy applications developed as COM and VSTO add-ins I find it hard to believe Microsoft would drop support within the next 10 years.
For me the most important differentiators of one approach vs. the other are:
COM/VSTO Office add-ins
Access to complete object model
Local machine interaction, e.g. file system
Available on Windows since Office 2007
JavaScript Office Add-ins
Portable between Windows, OS X, iOS etc. (not complete everywhere yet though)
Easy integration with online services
Easy distribution, no need to worry about installers
In your case I'd ask myself these questions:
Will there be a need to support other platforms besides Windows in the future? > JavaScript API
Are the requirements covered by the current JavaScript API implementation?
I've found that VSTO isn't 100% implemented either. I've given up developing VSTO for Project, got hit by too many issues. Instead I've developed everything in VBA and have perfected some neat ways to install, distribute and update VBA macros.
I plan on developing Excel Add-ins and I have looked around on ways of getting it accomplished. What I have found from expert views on various forums whom suggest using third party XLL development environments (XLW, ExcelDNA and host of others) instead of Excel SDK development 2007 with C++ as the latter option requires steep learning curve and for novices such as me would require managing low level details such as memory management
So my question is whether the XLL produced or developed using the 3rd party tools (XLW, ExcelDNA) would run on users Windows system that do not have .net runtime support. There are only 1 or 2 sample tutorials on the web about development of XLL with Excel 2007 SDK using Visual Studio.net and users comments on those tutorials suggest that an XLL developed in Visual Studio.net using Excel 2007 SDK are not runnable on Windows that do not have .net runtime
If you develop your add-in with C# or VB.NET (either with Excel-DNA or XLW), it will require the .NET runtime to be present on the client machines. If you develop the add-in with C++ (with XLW or another C+-based toolkit like XLL+) your add-in will not require the .NET runtime.
By default XLW uses the dynamically linked C runtime so you need to be sure the target machine has the appropriate version. http://xll.codeplex.com uses static linking so you can be sure your xll will run on any Windows machine.
It seems if you try to reference the Office COM objects (as you would do in other development environments), Visual Studio gets it wrong - and it just won't work.
So you must use the converted type library that Microsoft hand-converted and makes available for download, and download, and download.
Now it seems that in order for my application to run it needs the Office Interop code, which is contained in an assembly.
Now i don't want to force my customers to install the Office 2007 Primary Interop Assemblies, Office 2003 Primary Interop Assemblies or the Office XP Primary Interop Assemblies. i want an xcopy deployment.
If i manage to get a hold of Microsoft's copy of the interop assemblies, can i just copy them to by Bin/Debug and Bin/Release folders?
If i include the Office 2007 interop assemblies, will it work if the customer has Office 95 installed, or do i have to include all versions of the Office Interop dll's Microsoft has ever published?
This is a common question with a rather complicated answer. Mary Lee of MSFT is a great resource for information about this:
http://blogs.msdn.com/vsto/archive/tags/Deployment/default.aspx
Using ClickOnce to deploy is the closest you are going to get to an XCopy install of any application built on VSTO.
Also, check this post:
http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/1666d2b0-a4d0-41e8-ad86-5eab3542de1e/
Finally, Misha has a great blog:
http://blogs.msdn.com/mshneer/archive/2006/01/05/deployment-articles.aspx
The PIAs are specific to the version of Office you are targeting, so the 2003 PIAs are necessary for targeting 2003 and the 2007 PIAs are necessary for 2007. Automating Office 95 via managed code is something I have not done before, but I can imagine you are directly referencing the type libraries so a RCW is generated for you and has nothing to do with PIAs.
HTH
Colby Africa (MSFT)
From my own experience:
If you wanted to target Office 2003 and above, then you'd use the Office 2003 PIAs - and limit yourself to the Office 2003 API. The code would run on Office 2003 or later. You could still call Office 2007 functions using reflection, but that's not pleasant.
I imagine it's much the same story if your baseline version is Office 2000 - though I've not tried it, and I believe the earliest version for which Microsoft themselves provide PIAs is Office 2002 (XP).
You can create your own Interop assemblies for 2000, and I've no reason to believe that you can't do it for '95, though you're the first person I've ever seen ask for '95 support! It goes without saying that if you create your own Interop assemblies you'll need to deploy them with your application.
In any case, you want to use the highest Office version you can get away with as your baseline, so that you can support as many features as you can without resorting to reflection. You should develop your code on a machine which has only that version of Office installed.
In my case, I develop for Office 2003 and know that my users also have 2003. So, I ask them to ensure that they have the ".NET Programmability Support" feature enabled (which you can do via Office 2003 Setup via Add/Remove Programs if you choose the Change option). That option basically installs the PIAs to the GAC. For those users that can't do this, my setup program detects the lack of the PIAs and installs them prior to installing my application (as it does for the .NET framework).
XCOPY deployment? Yes, I'd like that too - but forget it. For one thing, if your add-in is going to work in 'high' security mode, then you're going to need a code-signed COM 'shim' to sit between your code and Office, and that needs to be registered. I believe VSTO provides its own shim, if you choose to go down that path (I didn't, since I needed to be able to 'drive' Office from scratch rather than relying on the user to start the application).
Deployment - and dealing with the installation & security issues - is one of the hardest parts of Office Add-in development with .NET, and it's a real kicker that it comes right at the end when you thought you were done.
My strong advice is to save yourself days and weeks of hassle, and look at Add-in Express. I've only recently come across this myself, and have been kicking myself ever since because it could have saved me so much time. It has several benefits that I think would be useful to you:
It allows you to create a single add-in targetting Office 2000 to Office 2007 (sorry, not '95), regardless of what version you happen to have on your development PC.
It creates an installer for you (which even works on Vista!), which in itself is worth the price.
It comes with its own COM shim, and is integrated to the extent that you don't need to worry about it.
It will allow you to have a single add-in that has a menu/toolbar interface in Office versions up to 2003, but a ribbon interface in 2007.
Note that I have no affiliation with Add-in Express (other than as a recent customer), but equally I've not yet converted my projects over to using it. The initial tests that I have done lead me to believe it's pretty good - and definitely the way to go for small to medium projects.
If i manage to get a hold of Microsoft's copy of the interop assemblies, can i just copy them to by Bin/Debug and Bin/Release folders?
It worked for me. When I compiled the program I had it reference the interop (PIA) dlls in the bin and then deployed it that way to the customer.
If i include the Office 2007 interop assemblies, will it work if the customer has Office 95 installed?
No, you mst have the interop dlls for the version of Word you are targeting. I suppose it might be possible to write your code so that it chcks the version of word running on that machine and at runtime chooses the correct interop, but you need to include them all.