"System.*" Files in Visual Basic? - vb.net

How are those files constallated and where can I find more information about them?
It is recent version of Visual Studio I'm using.

The different system assemblies live in the Global Assembly Cache (GAC).
You do not normally need direct access to these files - see How to: Add or Remove References By Using the Add Reference Dialog Box on MSDN.
The assemblies that are in the GAC will appear on the .NET tab of the dialog.
To use a namespace directly in the class (so you do not need to fully qualify it), use the Imports statement.

Related

How to fix Designer code when relocating a control to a custom namespace

I have a project with a custom control overriding a default control from the system.windows.forms namespace. This works fine, but I discovered I needed to modify a DLL this project depends on with some code that needs to know about the existence of this custom class; this code uses the class name of the control to do various things.
As the project depends on the DLL, and circular dependencies are not-a-good-idea, I moved the custom class to a third DLL which is a new project by cut-and-paste, and set the project and library to depend on this new lib, and set this new library to be built first, before the two other projects, and added an assembly reference.
So far so good; I can now import this new namespace and use it in my code. But, now the existing uses of the custom control are broken in any 'designer' based code, as they still point to the default namespace. I've tried adding a reference under Project Properties > Imported namespaces, yet this is insufficient: the code likely needs to contain the explicit line imports <myNamespace>. And while this is no-problem for regular files, when you have a designer file it's important to not manually modify it.
What's the easiest proper way of informing visual studio that any custom control named say X should now be accessed as myNamespace.X?
The procedure as done in the question is correct, with one caveat: Check the .NET version, and if different set the target version to the lowest common denominator. If you use a newer Visual Studio than the original that was used to make the solution, it's likely there's a newer .NET out as well. By default, the latest .NET will be used for new projects. Visual studio will also happily attempt to build the projects with disparate .NET versions, and complain that it can't find references, then surreptitiously hide the version mismatch as a "Warning", even though linking assemblies with different targets is by default impossible.
The designer will then happily accept the custom class even if it's defined in another project.

How to replicate referenced dll functionality with distributing .dlls.

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

Importing Autodesk.AutoCAD in VB.NET

For my project, I need to generate CAD drawing (almost a blueprint of a tank) through my VB.NET application. The app takes in some user input & based on this, it generates the geometry of the tank.
I am using Microsoft Visual Studio Professional 2012 & coding in the VB.NET language.
I have browsed through a lot of AutoCAD documentation but could not find exactly how & where are the modules hidden, for me to add them into my code.
I stumbled accross one particular document
which is where I found how to add the relevant files as reference to my VB solution. However, after adding some particular files I could then do Imports AutoCAD, but all the docs show that I must use Autodesk.AutoCAD. On inspection of the available modules/methods of the Imports AutoCAD I can see that it isn't complete as needed for the application development.
Can somebody please guide me as to how could I find or go about adding correct reference files to my VS solution to get full functionality from the AutoCAD modules? Thanks!
I posted this quite some time ago. It contains the information that you need
How to close a file in Autocad using C# keeping acad.exe running?
You can also download any of the AutoCAD .NET API's from here:
http://usa.autodesk.com/adsk/servlet/index?id=1911627&siteID=123112
Just in case someone else need the help.
Download the appropriate AutoCAD .NET API using the aforementioned link.
Put them in a location of your choosing.
general:
on the appropriate project in your visual studio's solution, right click -> Add Reference.
select Browse on left, click the browse button and go to the path where you saved the ObjectARX download.
Inprocess:
Navigate to the inc directory and
select the AcDbMgd.dll and AcMgd.dll then click add.
For these make sure to set the copy local property to false.
Interop:
Navigate to the appropriate directory: inc-win32 or inc-x64 depending on your processor.
select the Autodesk.AutoCAD.Interop.Common.dll and Autodesk.AutoCAD.Interop.dll then click add.
and unless you have an interest in the AutoCAD interface don't worry about the AcCui.dll
Hope this helps some one out :)
So, looking up more & more documentation led me to stumble across this
I found the dlls by simple file search for respective dlls metioned below in my local AutoCAD 2014 installation folder (C:\Program Files\Autodesk\AutoCAD 2014)
As per the documentation, following dlls are important ones -
AcCui.dll
acdbmgd.dll
acmgd.dll
Autodesk.AutoCAD.Interop.dll
Autodesk.AutoCAD.Interop.Common.dll
The credit for the last 2 dlls goes to Trae Moore.
How to add references to the dlls was mentioned in the documentation link.

VB6 reference confusion

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?

When adding a reference in a VS2008 C# form project, does Visual Studio copy the referenced assembly

into the project directory? Or does it simply reference the dll where it exists?
My assumption was that when you compile, it copies to dll into the local bin/debug(release) directory.
I am running into some issues with a project at work involving missing third party component dll's and I am a little confused, so I'm not sure how to proceed.
Thanks,
Kevin
By Default, If it is in the GAC, then it will not copy the assembly locally. If it is anywhere else, it will.
If you have any doubt, look under your references list and go to the properties of the assembly in question. There is a "Copy Local" property. If you change that property, it should copy to your output project. Redo your packaging and deploy.
A reference has a property named 'Copy Local'. If this is set to true then the assembly will be copied to the output folder.
It'll copy it if you tell it to in the properties for the reference. Indirect references (i.e. when a third party control needs yet another 3rd party control that isn't referenced) won't be, but I think you get a compiler warning if that is the case.