I imported a Form object from a text file. When I try to compile it I get the following error message:
This message is for C/AL programmers:
The OLE control or Automation Server identified by 'Microsoft Common Dialog Control 6.0 (SP3)'.CommonDialog requires a design time license.
This license cannot be obtained.
Make sure that the OLE control or Automation server is installed correctly with an appropriate license"
I am developing in Dynamics NAV using a developer license. The OCX is registered correctly, gets listed in NAV's "Custom Controls" as pointing to "C:\Windows\SysWOW64\comdlg32.ocx".
Why am I not allowed to compile the object?
The license in question is, as you said, purely for using the CommonDialog component in design-time environments. This has nothing to do with your NAV license or your customers being able to run code that uses the component. The design-time license (which is nothing more than a key in your system registry; not an actual license file) used to get installed with e.g. Microsoft Visual Basic 6.0 or older versions of Microsoft Visual Studio.
If you have access to VB6.0 or VS2005, you can use VB6Controls.reg on the installation disk as described here: http://support.microsoft.com/default.aspx?scid=kb;en-us;318597.
As the message said, the components loads, try to get a license and don't get one. So you don't have one as it says or you don't have it in the path lookup the components looks at it.
There is one more trick you can do to fix this problem and avoid installing a lot of crap like VB6.0.
This message is related to certain automation type variable in the object you trying to compile.
You can copy this variable from any other compiled object in other database or any other compiled object in the same database. And then your imported object will magically compile. Just delete the variable from your imported object's variable list and copy it from compiled object with copy-paste.
I don't know what magic is that but it worked for me many times. I copied variable from the same object in restored backup of the database.
Related
I'm also one of many who has begun development work in Business Central. I'm currently in-charge of migrating C/SIDE to AL. My question is, is there a way to identify whether something is in Object form or Extension form? The documentation I have from a third-party vendor says:
"All of company XYZ's products are available in both Object form and in Extension form. Existing customers who want to migrate from the Object version of a solution to the App version will need to go through a migration...."
First a little clarification:
Object form means that the modifications have been done through C/Side.
Extension form means that the modifications are isolated within their own package with one or more dependencies to other extensions. These are not visible in the C/Side Object Designer.
When modifications are done through C/Side the system generates symbols to simulate the extension interface. This provides the needed features to extend C/Side objects.
The easiest way to determine if a modification is in Object or Extension form is to check which extensions are installed on the system. This is can be done in two ways:
In the Business Central client go the the Extension Mangement page. Here all installed extensions will be listed (apart from a few hidden Microsoft extensions that you need not worry about).
Run the command Get-NAVAppInfo through PowerShell. This will list all installed extensions on the requested tenant.
I have a Web Site with an Service.svc file, i created this using the Add New Item -> AJAX-enabled WCF Service, for weeks, everything works fine.
Today, i imported the EPplus.dll to generate some excel files. When i try to compile i get this error
Error 1 Reference.svcmap:
Failed to generate code for the service reference 'QUAY.Tractebel.COP.Servicos'.
Cannot import wsdl:portType Detail: An exception was thrown while running a WSDL import extension:
System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Type 'OfficeOpenXml.ExcelRangeBase' is a recursive collection data contract which is not supported.
Consider modifying the definition of collection 'OfficeOpenXml.ExcelRangeBase' to remove references to itself.
XPath to Error Source: //wsdl:definitions[#targetNamespace='']/wsdl:portType[#name='Servicos'] App_WebReferences/QUAY/Tractebel/COP/Servicos/
I have no idea how to solve it, someone can help me?
Just had the same problem while referencing a custom wcf class i use.
The strange problem is that on my old development pc (windows vista 32bit, visual studio 2010) i haven't got this problem, it only pops up in my new system (windows 8 64bit).
Bah.
However, i bypassed the problem opening App_WebReferences --> "your service name" --> Right click on depending Refrence icon --> "Configure service reference"
In this screen move the option button from "Reuse types in all referenced assembiles" to "Reuse types in specified assemblies" and check all the depending libraries EXCEPT EPPlus
Compile and ... voila
If someon has also a logic explanation, i'll gladly listen
I am using the TcmUploadAssembly utility in a post-build event but am receiving the following error from the tool.
Error 1 Name must be unique for items of type: Template Building Block
within this Folder and its BluePrint context. Source or sources of
conflict:
tcm:5-200-2048. C:\Projects\Project1\src\Tridion\TBBs\EXEC Compound
Templates
The TcmId given refers to the Assembly stored in Tridion which I would expect because that is what I am overwriting. In the past this "just worked". Am I missing something?
Notes:
My user is an admin
The Tridion instance is on my network so I am using credentials in context.
I have specified all settings via the command line (no config.xml is used)
Any ideas?
I would say check your Blueprint context (i.e. the Publication you are in). This error means you are trying to create the TBB, yet there is already an item with the same name probably somewhere down in the Blueprint child Publications.
Classic writing out the problem and the problem solves itself...
I discovered the folder is set in the AssemblyInfo as well and I had the folder set incorrectly on the command line (Blueprinting issue).
I ran into a second problem however, if I set uploadpdb:true on the command line I receive this error
Error 1 Could not write file: c:\Temp
Setting uploadpdb:false resolves the issue.
regsvr32 filename.ax
I just see it said something installed successfully,but what's the whole story?
COM that is widely used in Windows relies on registration. A component will provide type libraries, interfaces and classes. Each of these are defined by a GUID to uniquely name them. COM components can also defined ProgID's that are kind of shortcuts to the unwieldy GUID's.
All this information is stored in a special registry hive on the computer named HKEY_CLASSES_ROOT. Use RegEdit.exe to view it. In particular you can find type libraries in HKEY_CLASSES_ROOT\TypeLib, interfaces in HKEY_CLASSES_ROOT\Interface and classes in HKEY_CLASSES_ROOT\CLSID. Some of the information in the registry will contain the path of the actual DLL with the component allowing Windows to locate and load the component when it is requested.
When you install a COM component it is necessary to create the correct registry information. By convention the DLL can provide two exported functions:
DllRegisterServer
DllUnregisterServer
When you execute RegSvr32.exe MyComponent.dll the RegSvr32.exe executable will attempt to call DllRegisterServer in MyComponent.dll. The DLL is then supposed to create all the necessary registry entries to allow the component to be used.
In a similar way you can use RegSvr32.exe /u MyComponent.dll to unregister the component. That will remove all the information previously added to the registry.
Windows relies heavily on COM and it is very important that COM registrations are up to date. Unfortunately there is nothing that blocks you from deleting an already registered COM component. This will leave dangling pointers in the registry pointing to the no longer existing DLL. You can't even unregister it since it no longer exists.
Another problem is when two different applications requires different versions of the same component. The registry can only point to one of the two versions, and this may cause one of the applications to fail.
Microsoft has created fixes for these problems. It is much better to provide an installer for the COM component that is able to repair and uninstall the component if it has been deleted. You are also able to create side-by-side installation of the same component in different versions.
It basically calls into your dll (named filename.ax in this case) and call its "DllRegisterServer" method.
In the case of directshow filters, it might "register" those filters in the windows registry so that directshow knows about them.
ex: https://github.com/rdp/directshow-demo-audio-input-open-source/blob/master/acam/virt_audio_all.cpp#L698 calls
https://github.com/rdp/directshow-demo-audio-input-open-source/blob/master/acam/virt_audio_all.cpp#L631
Though there are more simple versions out there.
regsvr32 registers DLL's and EXEs into the Windows Registry (usually COM Type Libraries, Class IDs, Interface IDs etc). You can use regedit to navigate the registry.
When ngen is executed on a .NET managed application at installation time, and a crash dump is retrieved from Windows Error Reporting for the app, how can you use it to see a stack trace, variables, etc.?
Here's some background related to the question: We have a .NET app that gets ngened at installation. When it crashes due to an unhandled .NET exception, the crash is bucketted in Windows Error Reporting, and from that I was able to download the minidump.mdmp file from winqual.microsoft.com.
I put minidump.mdmp in a folder containing the .dbg files for the build of the app that crashed, and double-clicked minidump.mdmp to open it in a new instance of VS2008 SP1. My stack trace looks like this:
kernel32.dll!RaiseException() + 0x3d bytes
mscorwks.dll!RaiseTheExceptionInternalOnly() + 0x295 bytes
mscorwks.dll!JIT_Throw() + 0x130 bytes
MyApp.ni.exe!000007feee74c84c()
[Frames below may be incorrect and/or missing, no symbols loaded for MyApp.ni.exe]
0000000070000d5e()
MyApp.ni.exe!000007feee611000()
000000000300bf78()
000000000300bf60()
The Modules window indicates that symbols are loaded for the OS and .NET DLLs, but for the application modules, I get this:
MyApp.exe -> No native symbols in symbol file.
MyApp.ni.exe -> No matching binary found.
MyAppsLibrary.ni.dll -> No matching binary found.
The easiest way to debug those dumps is with the Windows Debuggers (Windbg, cdb, or ntsd) and to load the SOS debugger extension (you can search for SOS for more details).
As far as I remember, the NGEN'ed part of thing shouldn't matter for SOS as long as you have the original EXE and the symbols (Since it's your app, I'd expect you have the non ngen'ed exe and symbols).
"Debugging Tools for Windows" (specifically, WinDBG) has limited support for managed apps. Provided with PDBs, you should be able to see the call stack, including source line references. To see variable values, you'll need to use the SOS plugin, which is more difficult that just opening the call stack window.
If you're able to request the clients to run your app again, ask them to run it with the following environment variable set: COMPLUS_ZapDisable=1
This way CLR won't load the native images when running your app and you'll see your usual modules with symbols on the stack.
http://referencesource.microsoft.com/faq.aspx
Is this of any help for you:
Symbol issue when debugging C# code
The guy seems to be able to load some symbols to debug his application from the crash dump, had a problem loading the correct symbols but someone answered his question.
Since this is managed code, you may need to set the _NT_EXECUTABLE_IMAGE_PATH environment variable to point to the folders where your executables live. In this case, you'll need to locate the folder in the NativeImage cache that points to your assemblies. The debugger needs the images in order to load the assembly.