Conversion of VB6 project to .net- references error? - winforms

I have a VB6 project when i try to tun this it throws some errors like
The referenced component 'AxMSCommLib' could not be found.
The referenced component 'AxOWC' could not be found.
The referenced component 'ComctlLib' could not be found.
The referenced component 'Microsoft.Office.Interop.Excel' could not be found.
and when i remove these references it shows the error where these references are used further like in this line
Public WithEvents ProgressBar2 As AxComctlLib.AxProgressBar
it says
Type 'AxComctlLib.AxProgressBar' is not defined.
Facing this situation first time, how to solve this, how to add these references in project or is there any other solution ?

As Patrik says in a comment, these are all COM object that needs to be registered before they can be used by a development environment (both VB6 and .Net). The error message you get indicates that these files are not registered on your computer.
You need to install the COM object dependencies. Find the original installation package for each dependency and run it. Hint - one of them is Excel. Another one might be the Microsoft Comm control (I forget the exact name).
Some people may advise you to try and register OCXs & DLLs manually, but it's faster to run the install packages, as the OCXs/DLLs may require other things in order to actually work.

Related

Using log4net on nmodbus from not-main-project in a WPF project

So, i'm taking over a old project that uses nmodbus (and old version at that, 2.0_1.11.0.0, we decided it was best to not update). Nmodbus uses log4net for logging messages. I need to be able to view the logged messages, but it seems like log4net doesnt like WPF, or being in not-main-project.
Adding
[assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config")]
To the Nmodbus project AssemplyInfo.cs file gives me this error:
Severity Code Description Project File Line Suppression State
Error Unknown build error, 'Cannot resolve dependency to assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.' OptimalProdTest
Adding log4net, with NuGet Package Manager, to the main (WPF) project causes Nmodbus to stop working. (maybe has something to do with log4net being an older version in the old nmodbus project, and adding with NuGet will download the newest? Can i somehow add log4net from the other project into the main project without NuGet?)
I found other people with similiar problem who said i should add:
FileInfo configFileInfo = new FileInfo("log4net.config");
log4net.Config.XmlConfigurator.ConfigureAndWatch(configFileInfo);
to "the entry point of your library setup your logger", one guy said, another said "in the constructor of the wrapper class". However, i do not know what files these guys are talking about, nor do i know which project they meant (add to main project or nmodbus?).
( https://social.msdn.microsoft.com/Forums/vstudio/en-US/0c5d7fbb-94a3-4221-ab91-9732c5acee58/cannot-resolve-dependency-to-assembly-because-it-has-not-been-preloaded )
I'm lost and i can't find much help when googling. Anyone has any idea what i should do to be able to view the logs from log4net in nmodbus?

Warning while adding primary output to the setup project

I'm trying to create setup for my project. I added the new project with "Setup . When I add primary output to the project, I got the following warning.
"The following files may have dependencies that cannot be determined automatically. Please confirm that all dependencies have been added to the project C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\Ltocxu.ocx C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\LtocxVariantu.dll
Please guide me to solve this problem.
Thanks in advance..
This warning is a "general" warning and not one that may necessarily stop the software from working. It only means that since OCX and DLL files are older technology, the new setup project may not be able to detect the dependencies for these files. You may want to check the LeadTools documentation or find the dependencies manually and add them to the distribution as required.
Again, since this is a general warning for the tool (setup project) itself and not your project specifically, even if you add any missing dependencies.
In this particular case, the warning might be valid. The old LEAD Main OCX (Ltocxu.ocx) did require additional DLLs to work. Some of them are directly linked as dependencies like the kernel and display DLLs (LtKrnu.dll and Ltdisu.dll).
Others are dynamically loaded if needed, such as file format DLLs.
You should be able to find full details in the topic "Files to be Included with Your Application" in LEADTOOLS help files for your specific version of the toolkit.

Add non .NET DLL to ColdFusion

I am currently faced with a dilemma in regards to adding any kind of DLL to a ColdFusion project. I have done a ton of research but nothing seems to be simplistic enough to grasp an understanding. I have a Winform that uses the same DLL in the Reference which makes life easy. When looking to add the same DLLs to a ColdFusion project, it doesn't seem to be working. I have tried using the following:
<cfobject type="com" name="myObj" assembly="C:\DocViewer\AxInterop.SHDocVw.dll">
Here is the error message I am receiving as well:
Attribute validation error for tag CFOBJECT. It has an invalid
attribute combination: assembly,name,type.
This site has been very helpful in the past and I am hoping to learn how this DLL in CF9 works so that I do not have to completely rewrite an entire program when the current one works perfectly.
From comments
I tried adding the DLL using the regsvr32 but here is my error now:
the module was loaded but the entry-point dllregisterserver was not found
Well it looks to me like you're using the cfobject attributes for a .NET object instead of for a COM object. The cfobject tag is one of those tags where the attributes vary by action/type, like cfcontent, cffile and cfdirectory (and a bunch of others that don't immediately spring to mind).
So you need the documentation for accessing COM objects specifically, which for the latest version of Adobe's CFML engine is located here: https://wikidocs.adobe.com/wiki/display/coldfusionen/cfobject%3A+COM+object
There's a typo on the docs page, but it looks like this should work for you (although I'll admit it's been a while since I've invoked a COM object):
<cfobject
type = "com"
class = "path.to.com.Class"
name = "myObj"
action = "create|connect">
It looks like you would use action="connect" if you have it installed as a Windows Service, or create if you want CF to instantiate the DLL, but I would guess having it installed as a service would be easier. I'm just guessing, but I think "path.to.com.Class" would be the name of the service if you're using it that way, or it would be the logical path to the .dll file if the CF server is instantiating it. If neither of those options work, then there might either be a version incompatibility if this is being moved to a newer OS, or the service might be misconfigured.
The error message from registering the DLL sounds like (and I'm guessing because I've never created a windows service DLL) it's looking for a specific class or function in the DLL in order to register it as a service in Windows and it can't find that "entry point" in the DLL (i.e. in the same way that Java will look for a "public static void Main(String args)" as the entry-point to a Java program). That may be necessary for a Service, but it's probably not necessary for a generic DLL that might be accessed and used in some other way, so it's possible this DLL might work, but not be compatible with Service registration.
So going back to your sample code, this might work:
<cfobject type="com" name="myObj" action="create"
class="C:\DocViewer\AxInterop.SHDocVw.dll">

Best practice to resolve the URI error

I have a main project (ProjectA) that contain a base class (xaml + code-behind).
Also, I have another project (ProjectB) in reference with ProjectA. In that last
project I have inherits some user-control created in ProjectA.
When launching the main application, I receive the follow error:
The component 'XXX' does not have a resource identified by the URI
'/My.Assembly;component/.../simplegridview.xaml'
Is there a best way to resolve that problem?
I know it is not really a solution to the problem. But I have found that Clean and Build makes the error go away...
I encounter the same problem with VS 2013 sometimes, without any immediate cause e.g. after a reboot and rebuild from scratch. In such cases the solution build succeeds, it also runs but still the error list displays e.g. 5 URI errors. While sometimes clean and build suffies, other times you have to close VS, delete bin/obj folders of the project with the errors, reopen VS and then the errors have gone.

Obfuscate Silverlight library using Dotfuscator

I'm attempting to use Dotfuscator 4.7.1000 to obfuscate a Silverlight library that is strongly named. When I attempt to do so, I get the following error message:
External type not found
System.Data.Services.Client.LoadCompletedEventArgs,System.Data.Services.Client,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
I have tried adding this assembly to the GAC, and have tried adding user defined assembly load paths to the configuration to locations where this assembly is located to no avail.
I then tried adding System.Data.Services.Client to the input assemblies and ran it again. This time it gets further, but ultimately I get:
Warning: Password protected Strong Name files are not supported
sn returned 1.
It appears as though it is attempting to run sn.exe on System.Data.Services.Client.dll with my local key. I've tried excluding this assembly from any obfuscation tasks, but it continues to do so.
Is there something I'm missing when trying to obfuscate this library? Is there some other way to directly point it to the DLL it can't seem to find that I don't know about? Or can I include the DLL in the project without it trying to obfuscate the Silverlight library?
And for the moment, please no suggestions on alternate obfuscators. My company has a license for Dotfuscator and I'd like to get this running using that. Thanks!
Somehow I must have been screwing up my user defined assembly load paths. As soon as I re-added the path to the Silverlight 4.0 client DLLs everything worked without having to reference System.Data.Services.Client.

Resources