I'm using the Crystal Reports Viewer 11 ActiveX control in an Access form (version 2007, 2003 format). Everything works well on my development machine, where I have CRXI installed. I copied the referenced DLL to the client's machine, but when I try to register it, it says "Can't find module" (I double- and triple-checked my spelling) and when I try to open the form it tells me "ActiveX component can't create object" when the code tries to create a new instance of the report object. I suspect there are more dependency files required by the DLL, but I'm a little at a loss as to what ones and how I go about finding out. Although I'm using the CR control, I assume this would apply to any ActiveX control throwing this error. Thanks.
There should be a runtime distribution document in your Crystal Help files - from past experience (Crystal 8.5) there are multiple files that you have to distribute and register.
I'm answering my own question in case someone finds this via a search in the future. I don't have the Access Package & Deploy wizard David mentioned above (okay, I probably have it but couldn't find it readily) but I image it would probably do what I needed, so I recommend anyone try that first. Instead, I was able to create a setup to install tghe needed files using the Visual Studio Installer and the Crystal merge modules; note that while it wasn't difficult, nor was it pleasant.
I downloaded and installed Visual Studio Installer 1.1 from MSDN. This creates a new project type in Visual Studio 6.0 (in particular, I used InterDev 6.0) that creates a Windows Installer (*.msi) setup file. Because one of the Crystal merge modules requires the Crystal license key and VSI doesn't support merge module parameters, I also had to use Orca, a merge module editor, available from the Microsoft Windows SDK (also available on the Microsoft download site). I recommend reading through the SDK and Orca pages on MSDN for more info. Using Orca, I was able to put my key code and recompile the merge module, so I don't have to deploy my key to my users, and my users don't have to enter one.
Again, the Package & Deployment Wizard is probably a better option, but when faced with using merge modules, as with Crystal, this method will get the job done.
Related
At this moment I'm working on a MS Access database, and I have difficulties with the library MSCOMCTL.OCX.
The problem is the following: given Windows 7 x64, Microsoft Office 2010 x64 and MSCOMCTL.OCX v6.1.98.34 (which was registered with the help of regsvr32 in the folder SysWOW64), I can't use the TreeView (MsComCtlLib.TreeCtrl.2 class) present in some forms of the database. Every time the code approaches any TreeView's (read, Node's) property, I receive the following message:
"Object doesn't support this property or method" (Error 438)
while in Windows 7 x32 the database works fine.
Trying to understand what's wrong, I discovered that the library Microsoft Windows Common Controls 6.0 (SP6) exists in the list seen in the 'References...' dialog and is checked, but I don't see Microsoft TreeView Control 6.0 in the list of available ActiveX Objects when I'm in the Constructor mode.
Following some solutions found in the Internet, I executed regedit.exe and saw that there are two "folders" in the path HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}, "2.0" and "2.1". Besides, the path to the file MSCOMCTL.OCX is in "2.1", while "2.0" is not also empty - it contains PrimaryInteropAssemblyName property for example, which isn't present in "2.1".
So, what should I do to make TreeViews in my database work? As I've mentioned before, I saw some solutions, but I'm afraid to use them because the computer, where the database is in, is not mine and it's undesirable to make the changes, which can affect security of the system.
The version of MSCOMCTL that is installed by default is not 64-bit compatible. You're unfortunately out of luck. No amount of modifying the registry is going to make a 32-bit only control work in 64-bit office.
However, MS apparently includes a 64-bit compatible version of MSCOMCTL with Office 365 ProPlus installations (source). You can consider buying that, or obtaining it through other means.
I've been developing UWP app until I got this error (picture below). I've searched for solution but I couldn't find anything. It doesn't even say which package is the incompatible. How can I find the incompatible package in my solution? Also is there any way to re-create project.json by automatically? I ask it because I changed something on project.json and broke it more.
Also I'm using VS2017 and I'm able to run project without issue. I just can't update package.
Thanks.
(github link for project if you want to look at it.)
I used your GitHub https://github.com/almorax/dota2-handbook-uwp project to troubleshoot the problem and looks like the problem is with the way the nuget package is referred in "Dota2Handbook" project. In other projects, you have used "PackageReference" way to refer the nuget package however in "Dota2Handbook" project you are using project.json to refer nuget package. When I changed "Dota2Handbook" project to use the "PackageReference" way then I was able to get the latest package.
Note: You will notice that "Dota2Handbook.Infrastructure" project already use the new way to refer Nuget packages
More details on PackageReference : https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
What happened to me is that I have UWP projects that were made in VS 2015 and initially targeting Windows 10 RTM. These projects where updated to VS 2017 and to target Creator's Update. All worked fine, and all projects still used the original project.json style.
Then I tried to create a new Windows Runtime Component project and target Creator's Update initially. Targeting Creator's Update in VS 2017 causes the project to use the new PackageReferences project style. This produced the errors shown in the above question when I referenced the WinRT component from the UWP app.
Rather than converting the all of my legacy UWP project files to use the new format, I target the new UWP or WinRT Component library to Anniversary Edition (which uses the older project.json project style), then retarget to Creator's Update.
Of course, at some point updating the project file may be appropriate, just know that it will no longer be supported by VS 2015. Conversion steps are illustrated here.
Attempting to submit a Windows Phone Silverlight 8.1 app to the store. Solution has several projects, including a Models, Contracts and a Shared DLL. These 3 projects/dlls are failing the Windows App Certification Kit tests with:
File XXX.Shared.dll has failed the NXCheck check
File XXX.Contracts.dll has failed the NXCheck check
File XXX.Models.dll has failed the NXCheck check
Microsoft say the problem is a Security threat issue, because these dlls are running code that is stored in a data segment.
The suggested resolution from Microsoft is to add the /NXCOMPAT switch to the Linker options, however, I do not have a Linker page in the properties in any of the 3 offending projects. I've tried adding this to the compilation symbols, but no change.
These DLLs are low payload - they contain not much more than POCO data objects, interfaces and a few static methods. I've built a new default blank Windows Phone app and added these projects to the Solution. If I reference any one of these projects in the main phone app project, the certification fails with the same result.
So the problem is definitely isolated to these 3 projects. There are other projects of the same type included in the solution, but these do not exhibit the same problem.
Does anyone have any ideas as to what these DLLs could contain which causes this Binary Analyzer failure?
I've compared compiler / build options and checked the project properties etc, but can't see any obvious differences.
This was due to a post-compile Build Event referencing an obfuscation library in each of these projects. Solution was to remove it as the library was third party.
I am trying to strongly name a 3rd party API that I have the code for but it's using a 3rd party DLL/NuGet Package that is also not strongly named and I'm having a lot of trouble.
I'm using the Box Windows SDK and the API was written in the .NET portable subset and supports .NET for Windows Store Apps, .NET Framework 4 and higher, SL4 and higher, and Windows Phone 7 and higher. Granted, I do not need all of these but I do need the .NET 4 and Silverlight versions. The API already works wonderfully and runs fine on its own. It would with my application also, if all my projects were unsigned but they aren't. We use strongly named assemblies for our Silverlight application in order to make use of application library caching.
Anyway, I have the source code for the API so I simply added my PFX file to the project to sign it. I then get an error that a dependency that this API is using called NitoAsnycEx.dll is not signed. I do not have the code for Nito.AsyncEx.dll but normally this isn't such a problem, more of an annoyance. So now I have an age-old problem of needing to take a 3rd party DLL of which I don't have code for and sign it with my PFX or another SNK file.
I can do either and normally I use one of the processes so wonderfully explained in this post by Ian Picknell: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html. So I have followed that process and the IL signing tools seem to sign the DLL just fine.
To make a long story shorter, let's use the simplest version of the signing process where I already have a simple SNK file ready to go. Basically, I do this:
I can run ILDASM to get the .il file for this 3rd party EXE:
ILDASM Nito.AsyncEx.dll /out:Nito.AsyncEx.il
I can then run ILASM to get the signed DLL:
ILASM Nito.AsyncEx.il /dll /resource=Nito.AsyncEx.res /key=NPSAssemblyKeyNoPassword.snk
It works great and I get this result:
Method Implementations (total): 118
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully
So now I have a signed DLL. I go back to my 3rd Party API code and remove the old reference to NitoAsyncEx.dll and put a new one to this. I try to compile and then I get an error like this:
Error 44 The base class or interface 'System.Object' in assembly 'System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' referenced by type 'Nito.AsyncEx.AsyncLock' could not be resolved r:\Data\GM\Source\GrantManagement\GrantManagement\3rd Party\Nito\Nito.AsyncEx.dll
I figure there is some problems using the portable .net library here but I'm not sure what it is. This same process normally works for me for Silverlight 4+ and Full .NET 4.5 framework libraries. Is there another ILASM or ILDASM set somewhere that will disassemble and reassemble the portable code correctly? Is this even possible?
I also tried to go and get the source code for the NitoAsyncEx.dll, which is open source btw, and compile it but that source code will not compile as it's missing some files. So currently I'm stuck with my integration of this API into my project and need a little assistance from any experts in the community.
Is there a way to sign this DLL correctly so we're not missing references to basic classes such as System.Object?
Is there a way to get around needing to sign this DLL at all and having it referenced from my projects?
UPDATED
The Box SDK has been updated and is now strong-named on nuget. This is thanks to the recent update to AsyncEx which strong-named the assembly.
As you mentioned, it's unfortunately out of our control that the NitoAsyncEx library is not strongly named. This library provides the ability to properly lock resources during an async/await call, and I do not believe there is a better alternative at the moment.
This being said, I may have a (hopefully temporary) workaround for you. I've downloaded the source from https://nitoasyncex.codeplex.com/ and was able to get it to compile. These are the steps I performed:
Removed the reference to MSBuild in the csproj
Copied the missing Dequeue.cs file from the packages folder
Resolved missing nuget references
Regenerated the AssemblyInfo.cs
Excluded the .tt template files from the project
Unloaded all other projects the SDK does not use
Here's the resulting solution:
https://cloud.box.com/s/7ikurtyajqmhq9p8q52x
I've successfully ran the resulting dll through the SDK's tests so hopefully this should cover what you need. I cannot guarantee the stability of this method, but having a working source should allow you to do any signing you need. From there, you should be able to drop the signed assembly into the SDK source and sign that assembly as well.
I have a database in ms access 2007 with forms. I need to create a stand alone exe file from access. Is it possible? If so, how?
You can't save it as .exe, but you could use the Access Runtime to allow users without Access to use your Application.
If I can just add my two cents worth...
You DO have to distribute the Access runtimes with your application. I heard recently on Stackoverflow on a questions that Microsoft runtimes for access are now freely downloadable.
Here are a couple of links...
http://www.granite.ab.ca/access/developeredition2007faq.htm
http://blogs.msdn.com/clintcovington/archive/2007/01/30/the-runtime-and-developer-extensions-will-be-free.aspx
You can either distribute these runtimes with your application or you can have your customer download them.
EDIT - THE BELOW IS PROVEN FALSE. YOU DO NOT HAVE TO PURCHASE A LICENSE TO DISTRIBUTE THE RUNTIMES. Of course, they are distributed under a license but the license is free. I leave the comment below for its historical interest.
I think but am not sure that to distribute the access runtimes with your application you will have to have a license. I know that you used to get this license with an MSDN subscription and with Visual Studio Tools for Office.
END FALSEHOOD
Once you have the Access Runtimes, you can create BULLETPROOF runtime installations of Access apps using preconfigured installation scripts from SageKey.com.
Office developer tools comes with some deployment options but they are not bulletproof and I would NEVER distribute a commercial application using those...they just don't work. But the sagekey scripts absolutely ROCK. They work incredibly well.
All this presumes you want to widely distribute your app. If not (for example...you want to just deploy to your customers and you will have complete control over that) then you can use the download from Microsoft option mentioned above.
One last thing. Runtime access apps have to be VERY robust. You have to do error handling and automatic table linking very well among other things or you will spend all the time on the phone with your customers rather than selling/distributing software.
Hope this helps.
Seth
If you have the Developer version of MS Access, you can create an '.mde' file, which operates just like an .exe file as far as your user is concerned. Essentially, creating an .mde wraps a version of the MS Access run-time along with your database.
As long as you have done a decent job with your form design, the user really can't tell the difference between your .mde file and a .exe.
I haven't used the Developer version in a number of years, but if I recall, it is quite expensive. EDIT (It appears to be free these days).
Here is a link to a good FAQ on the topic. Much more up-to-date than my recollections from the past.
As far as bullet proof runtimes yes Sagekey is an answer. However another alternative is Albert Kallal's Inno script which checks to see if a version of Access is installed. If not it tells you to install a runtime version of Access. If installed then it continues to install your FE MDE and other assorted files.
http://groups.google.com/group/microsoft.public.access/msg/10e3fc9234660872?hl=en
Sample inno script which "wraps" the package wizard install into a single .exe
http://groups.google.com/group/comp.databases.ms-access/msg/4aa1b33a191bf1f8?hl=en
Deploying updates to your software in a Runtime environment for Access 2007
http://www.members.shaw.ca/AlbertKallal/RunTime/InstallExample.htm
The only scenario which it wouldn't handle well would be if the user does install Access or a different Access runtime on their system later. However if you ship your product in Access 2000 format the problems are minimized.
no it's not possible.
I don't believe it is possible. Sorry to say. You need the Access to launch and display the form.