I have a vb.net application I'm looking to be able to distribute in the near future.
I'm not the original architect and the previous developer referenced a handful of .dll's that are under a GPL license.
All of the software that includes these dll's are freely available online, so my customer can go download and install them if they need that functionality. So I don't have to distribute the DLLs.
Currently they are referenced under the "Reference" part of the project file.
My question is, how do I resolve these dll's in a way similar to how the "references" dons it, but at runtime.
My plan is to search the registry for the location of these dll's and reference that location, but given the file location of the .dll, how do I "pull" that code into my project.
Thanks
You may try this
Search for Dll on specified path for dll
Use reflection to load assembly or dll into you code at runtime
Create runtime object from the loaded dll
Call required functionality from the dll
Reflection is the key solution to your problem that you may use to plugin new functionality into your project without distributing the dlls
This is the only solution that works
http://mylifeandsql.com/2018/03/26/replication-readpast-error/
also you can just start your migration with the following command
Sql(#"SET TRANSACTION ISOLATION LEVEL READ COMMITTED");
This will replicate dll changes like adding new column to a replicated table
You will also find that the column is automatically added to replicated articles > columns
No need to create a new snapshot nor set the sync to re-initialization ☺
Thanks
Related
I am a .NET Developer. I have a good understanding of how references work in .NET i.e. if you want to use AssemblyA.ClassA.MethodA in AssemblyB.classB.MethodB then you add a reference in Assembly A to Assembly B.
I am looking at a VB6 app and I get an error when I open it i.e. Errors during load. Refer to frmMain.log. I open frmMain.log and it says: "2142: Class MSComDlg.CommonDialog of control CommonDialog1 was not a loaded control class.". I have used WinMerge to compare the source code in the faulty project to a previous version of the project (which does not have the problem). The only difference is that the faulty project contains the following line in the client.vdp file:
Reference=*\G{08DBEFD7-6A19-4DCE-A533-5BDBB93683C8}#1.2#0#..\..\..\..\..\Windows\SysWOW64\Comdlg32.oca#Microsoft Common Dialog Control 6.0 (SP3)
Removing this line seems to resolve the problem. Why does this resolve the problem?
I have used Winmerge to compare yesterdays revision of the project (which does not have the problem) to todays revision of the project (which does have the problem). The only difference is the reference in the original post in the VBP file.
I would assume that someone installed the development version of this control on a different machine and then set a reference to it. When you try to open the project on your machine the reference fails. Or the control was uninstalled. It seems that the project was not using the reference and that it can be safely removed as it will still compile without the reference.
However, I have seen vb6 actually remove non-licensed controls from the form in question in this situation. So it may be that you can now compile because the form is missing a component that was there previously. Have you checked that frmMain has not changed, both the .frm and .frx files?
I have a native app that has an .OCX file that needs to be registered for it to be used in a .NET application.
Now currently there's different versions of this .OCX on the machine. Can someone please explain how this can affect the registration of this new (updated) .OCX file registration?
And how does my .NET app know which object to create from which .OCX file?
COM servers are required to change their CLSID guids if their interfaces are no longer compatible. So if your supplier did it right, you should be able to register both of them and get the right one when you use the right reference in your project.
Like any rule, this one got violated often and is presumably the reason you started this question in the first place. The back-up plan is to use registry-free COM, you write a manifest and add it to your program so it always uses the local copy of the COM server DLL instead of the one that was registered. Find out how to do this by googling "regfree COM", I see many relevant and useful hits at the top.
I believe COM class registrations include the entire path to the "server" providing the COM component. If the two versions of the .OCX have different class GUIDs, then there should be no issues.
I know there are many questions out there regarding this same information. I have read them all, but my brain is all turned around and I don't know which way to go. Plus the lack of documentation really hurts.
Here is my scenerio. We are trying to use WIX to create an installer for our application that goes out to our dealers for our product information. The app includes about 2000 images and documents of our products and a SQL CE database that are updated via Microsoft Sync Framework. The data changes so often that keeping these 2000 as content files in the app's project is very undesirable. The app relies on .NET Framework 3.5 SP1, SQL Server CE 3.5, Microsoft Sync Framework 1.0 and ADO.NET Sync Services 2.0.
Here are the requirements for the app:
The dealers will be given the app on a CD every year for any updates (app or data updates).
The app must update itself from the internet to get any new images, documents or data.
The prerequisites must be installed if they do not exist on the client machine.
The complete installer should be generated from an MSBuild script with as little human interaction as possible (we don't want to be manually updating the 2000+ file list).
What we have accomplished so far is that we have a Votive project in our solution. We have manually specified the binaries in a .wxs file. Web have modified the .wixproj file to use the HeatDirectory task to gather our data (images and documents and database) from a specified location (This is broken and giving an ICE38 error). This seems all right, but still is a lot of work. We have to manually update our data by running the program in release mode and copying it to the specified directory.
I am looking to see what other people would do in this situation.
How would you arrange your solution with regards to the 2000+ data files? Would you create a custom build script that gets the current data from the server or would you include them as content files in the main project?
How would you get WIX to include all of the project output (including the referenced assemblies) and all of the data files? If you have any complete samples, that would be great. All I have found are little clips here and there and not an entire example from start to finish.
How would you deal with the version numbers? Would you put them as a constant in the build script and reference them through the $(var.VersionNumberName)? Would you have the version number automatically picked up from the project being deployed? If so, How?
If there is any better information than what I am finding, please include. I have read numerous articles, blogs, Stackoverflow questions, the tuturial, the wiki, etc. Everything seems to be in bits and pieces. The tutorial is nice, but doesn't explain anything about MSBuild and Votive. I would like to see a start to finish tutorial on using MSBuild and Votive and all the WIX MSBuild targets. If no one knows of a tutorial like this I may put one together. I have already spent the entire week gathering info and reading. I'm new to MSBuild as well, so if anyone has any great articles on MSBuild, please include them.
The key is to isolate the different types of complexities into separate merge modules and put them altogether into an MSI as part of the build. That way things that change often can change without impacting things that hardly change at all.
1) For the data files:
We use Paraffin to generate the WiX and hence the merge modules for an html + Flash based help system consisting of thousands of files (I can't convince the customer to go to CHM).
Compile these into a merge module all by themselves.
2) Assemblies: assuming that this is a set that changes less often just make a merge module by hand or with WixEdit with the correct files and dependencies.
3) For the version number there a lot of ways to manage this depending on your build system. The AssemblyInfoTask is pretty straight forward way to make sure all your assemblies are versioned appropriately. The MSBuild Extension Pack has some versioning stuff if you are using TFS.
I had a similar scenario and was unable to find a drop in solution so ended up with the following:
I wrote a custom command line program called wixgen.exe for generating wxs manifest files. It is pretty specific to our implementation in that it only knows how to create 2 types of wxs files. One for IIS Website/Virtual Directory deployments and another for Windows Service deployments.
Each time a build is triggered by our continuous integration server a post-build task runs wixgen with the right args to generate a new manifest.wxs for the project being changed. It automatically includes all the files needed for the deployment. These builds also version the dlls using a variation of the technique at: http://richardsbraindump.blogspot.com/2007/07/versioning-builds-with-tfs-and-msbuild.html
A seperate build which is manually triggered is then used to build the wixproj projects containing the generated wxs files and produce the msi's.
I would ditch the CD delivery (so 90's) and got with ClickOnce. This solution seems to fit well since you already use the .NET framework. With ClickOnce you should be able to just keep updating the content of your solution and make updates available to your heart's content. Let me know if you need, sample ClickOnce deployment code.
You can find more ClickOnce information here.
Similar to dkackman's answer, you should seperate your build into several components, isolating build components to be built seperately.
I come from a mainly Java background, however for building MSIs and NET executables we use maven; with the 'maven-wix-plugin' plugin for building the installers, and using the NMaven plugin for compiling any NET code. However, as we're only performing very basic development in NET, with most development in Java, we don't need too much complexity from the NMaven plugin (which is probably a 'good thing' (TM) as it's only at version 0.17).
If you're a purely NET house, you could also look into Blydan (http://www.codeplex.com/byldan), which seems to be the focus of development there at the moment (it's the same team for NMaven and Byldan).
If you do want more information on NMaven or Byldan raise another question and I'll give as much info as I can (which is not a huge amount, as stated I only do very limited NET development).
I am getting error,
ActiveX component can't create object.
Actually I have VB6 DLLs where business logic resides and I am calling that DLL function in my VB.NET application, all DLLs are dependent on other DLLs. I am getting the error from one of the DLLs
Any ideas?
Usually that error points to a COM dll that is not registered. You need to look at the chain of calls and find out which COM components you need and make sure they are available. Process Monitor (from sysinternals) may help you find it when it reads from the registry and can't find it.
Four common causes are:
1. You do not have a required TLB or ActiveX DLL/OCX file
2. A TLB or ActiveX DLL/OCX needed by the project is present but not registered on your system
3. The VB runtimes are an earlier version than the one you need to run the project
4. A required TLB or ActiveX DLL/OCX file is corrupt
Do you have access to the troublesome DLL source code?
Also check permissions. The user account that the vb.net application is running under will need permissions to be able to create the vb6 dll
Process Monitor will definately help find the missing DLL, but frequently the task can be achieved more quickly with Dependency Walker.
I have been trying to load a OCX file into one of my VB6 projects for most of the day today. I've tried checking the COM registration in the registry the best that I know how, and have attempted several times using REGSVR32 on the file to no avail. All I keep getting from VB6 when I try to load the component (Under Project --> Components) is 'FilePath\FileName.ocx' could not be loaded. Has anyone else seen this before, and if so, any ideas how to fix it?
Just a couple of tips to help isolate the problem....
Look at the control with OleView
Examine the name: if it is one of the reserved words such as 'Menu', vb6 will fail to load it. (Although vb6 will happily let you create (and use) one with a bad name until it is saved and reloaded)
Examine the interface: does it describe the functionality? You may have a damaged or unlicensed ocx.
Attempt to load it with the ActiveX Control Test Container...
If you can, the problem is with VB6 and not the ocx.
This it may be a dependency issue -- some other component needed by the OCX is not present. Dependency Walker will find any static dependencies.
We fixed similar error recently. In our case the error was in the Visual Basic project (.vbp) file. Project file had been edited outside standardized build machine and contained references to OCX components - including workstation specific paths & versions of the components.
You can either edit the the project file in text editor or get a working version from version control.
Un-registering and registering again worked for me too.
Please note that you need to register this component using this syntax:
regsvr32 /i:design olch2x8.ocx
When you say you have used "REGSVR32 on the file to no avail" do you mean that you get a file name succeeded message, or an error message? If registering the file succeeds CMB is likely right about the ocx being unlicensed.
Licensing aside, there are a couple of other trip points with vb6. Especially if the OCX was developed in VB6.
If so, the 'officially' system registered version may conflict with the specific ocx you're using. In other words, both of them might have the same proper name (or classid) but the one you're attempting to use may not implement all the functionality described in the system registered one (i.e. you have a less evolved version). This arises when the author desires to maintain binary compatibility while enhancing the functionality of a control. As long as the public interfaces remain compatible, vb will not recalculate the classid.
You can fix this by forcibly unregistering the specific control (actually unregister all instances of the control). (regsvr32 /u control.ocx ) Then re-register the one you intend to use. Be certain that no running instance of VB6 exists when you do this or the results might not work. (Check your task list)
Hope that helps...
The control may be reliant on another DLL or OCX that may be missing or not registered and this could manifest itself as VB reporting that the control you're trying to use is missing. However, I'm not sure how you would identify the dependencies. As far as I know, dependency walker identifies static dependencies; I'm not sure if it can identify COM dependencies.
Un register the Ocx
re register the ocx
then loaded the project again in VB6, it worked for me.
Thanks everyone