I'm using Aspose.Cells DLLs Version 7.0.0.0 on 64-Bit Windows 7 with .NET 4.0 on my machine. It does work on my friends machine, which is running 32-bit windows 7 also with .NET 4.0 - I suspect difference in windows version (x64/x86) could be a problem.
using Aspose.Cells;
using NUnit.Framework;
namespace BSF.IntegrationTests.Services.FieldConverters
{
[TestFixture]
public class Useless
{
[Test]
public void VerySimpleTest()
{
new Workbook().Save(#"C:\NewFile.xls");
}
}
}
Aspose.Cells is not open source AFAIK, and there is no way for me to look at the Save source code and come up with some workaround.
Aspose.Cells for .NET works fine on 32-bit and 64-bit systems. You may check the topic 'Using Aspose.Cells for .NET on 32-bit and 64-bit systems'. Just make sure that you're using .NET 2.0 version of the DLL included in the package. You may also try the latest version of the component. If you still find the same issue then you may report it to Aspose.Cells support team.
Related
I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !
Background:
I have an existing code that uses functionality provided by Microsoft, to post XML data over HTTP. Specifically, IServerXMLHTTPRequest (included in MSXML3 and up) from msxml4.dll (COM).
The Problem:
In the possible eventuality, were MSXML4.DLL is missing on the client workstation, the described POST operation will simply fail. More information about MSXML versions.
The current code:
#import "msxml4.dll"
using namespace MSXML2;
…
IServerXMLHTTPRequestPtr spIXMLHTTPRequest = NULL;
hr = spIXMLHTTPRequest.CreateInstance(__uuidof(ServerXMLHTTP40));
Alternatives:
Hard code to MSXML6 (instead of MSXML4). Not a good solution as we do not know what MSXML version is installed on the workstation. Also, the code will break again if Microsoft will release the next DLL version.
Dynamically load the latest from the registry:
Find MSXML version from registry and
Dynamically load a function from a DLL
Use the type library instead?
I would be happy to hear additional alternatives
The question:
What is the simplest and most robust way to change my code to be MSXML version agnostic? That is, use IServerXMLHTTPRequest regardless of the MSXML version actually installed on the client machine. If no version of MSXML is installed, prompt the user and exit gracefully.
Need additional information? Just let me know
Thank you!
From MSDN:
MSXML version 3.0 was the last version of MSXML to support version-independent GUIDs and ProgIDs. Starting with version 4.0, MSXML is installed on your computer in side-by-side mode. This means that, for example, installing MSXML 5.0 for Microsoft Office Applications does not replace any previously installed version of the MSXML parser on your computer. This is done to protect the quality of applications that are currently using earlier versions of MSXML. Side-by-side mode also allows you to decide which version of the parser to use in your code.
This means that there is no COM class installed which you can instantiate expecting that most recent installed version will be picked up, or otherwise someone else will decide for you whether to load MSXML 4 or 6 depending on availability or another criteria.
You are expected to use specific version and depend on respective runtime to be available or installed. Or you can switch between MSXML versions in your code as you already discovered.
I would like to be able to get the version of SAPI that my C++ application is using, and then display it to the user.
The problem is I cannot figure out how to get the version out of the SAPI interface.
_SAPI_BUILD_VER is a constant in sapi.h (and sapi.idl) that defines which version of SAPI you're building against.
It's based on the Win32 build version (_WIN32_WINNT).
For Windows 7, it's 0x054; for Vista, it's 0x053, and for XP, it's 0x051.
If you need to find out at runtime, QI for interfaces that are only defined in 5.4 (ISpRecognizer3, for example) or 5.3 (ISpRecognizer2).
For voices, generally speaking, the available voices change depending on the installed version.
I'm trying to import a third-party .NET type library (COM server DLL) using tlibimp.exe (version 11.0). This basically works fine, but the results differ when I run it on different computers, one running Windows XP, the other Windows 7. What's worse, the code generated on the Win7 machine doesn't compile.
Both machines have:
Borland C++ (RAD Studio) 2007
tlibimp.exe version 11.0
the same .NET framework versions installed (as far as I can tell,
Borland 2007 uses .NET v2)
bcc32.exe version 5.93
The compiler fails in the OCX.h with:
Parameter mismatch in write access specifier of property Font
The relevant line of code on the XP machine (which compiles ok) is:
__property Graphics::TFont * Font={ read=GetTFontProp, write=_SetTFontProp, stored=false, index=-512 };
The same line on the Win7 machine (which fails) is:
__property IFontDisp* Font={ read=get_Font, write=set_Font, stored=false };
Now I'm not really sure where this difference comes from. Any ideas?
cheers
Hendrik
This may or may not help but I had a similar issue trying to import two type libraries into delphi, from c sharp assemblies.
One type library (A) inherited from TOLeServer, the other (B) from TOleControl and I couldn't see why, as both assemblies which generated the type libraries were virtually identical.
The issue turned out to be that B had been registered with regasm and A hadn't. Registering A and re-generating the type library solved the issue.
Is it possible to build a managed c++ project in .net 3.5 using vs2010 ?
There are different opinions around but I haven't being able to do this. Any ideas?
The build system for VS2010 was dramatically changed and only directly supports building for 4.0. Targeting 3.5 requires having VS2008 on your machine. More about this in this answer.