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.
Related
For example this happened to me when I added configuration (IConfigurationRoot) in the Startup.cs file, to be able to access appsettings.json file which has a connection string.
So the first time I write IConfigurationRoot it is obviously marked as not recognized, so I put my mouse over it and expand the Visual Studio suggestions from the light bulb, which are:
using Microsoft.Extension.Configuration:
Microsoft.Extension.Configuration.IConfigurationRoot
Generate Type
Add package Microsoft.Extension.Configuration.Abstractions 1.1.0
So if I pick "using Microsoft.Extensions.Configuration",a using directive is added at the top of my file and VS recognices IConfigurationRoot, everything works fine. But checking the References in my project, this library was not added to it:
No Reference Added
So if instead of picking the using directive, I pick "Add package Microsoft.Extensions.Configuration.Abstractions 1.1.0", Visual Studio also adds the using directive but additionally it adds a new Reference:
Reference Added
I'm not understanding why this happens, why adding the using directive (first suggestion) works fine, is it because the reference is already contained in another library?, if so, why should I add the package individually?. Is it better to add it individually?, what happens if I do, am I adding a reference to the same library twice?
Thanks in advance.
...is it because the reference is already contained in another library?
Yes, look under the Microsoft.Extensions.Configuration.FileExtensions or Microsoft.Extensions.Configuration.Json and you eventually get to the Abstractions package.
If so, why should I add the package individually?
There is no need. The light bulb tooling might not quite up to speed with the whole package dependency stuff.
Is it better to add it individually?
Not really, but if your ever removed some of those base package then adding it individually from Nuget would ensure that it would remain.
What happens if I do, am I adding a reference to the same library twice?
In an indirect way, yes, but there's no harm. The Dependency tree view drills down into each layer of dependencies. You will see lots of "duplicates" if start expanding those nodes.
We've got a visualstudio solution with all our code in it and it's completely seperated from our unity project.
When we build our code into a dll from within visualstudio, the dll is copied over to the unity project plugins folder, so we can use the classes from it in our unity project.
This all works fine, but the problem is when we rename a class in our visual studio solution, rebuild the dll and go back to the unity project, the reference to the renamed class is lost in our scene and/or prefabs...
I looked into the scene & prefab files and noticed the references to the classes in the dll are defined as follows:
m_Script: {fileID: 698634159, guid: aa20b9c3579870b40bb96d13672546a3, type: 3}
I read on the forums that the fileID is generated based on the namespace & name of the class file, so logically when the class is renamed, this fileID changes and unity does not know it needs to reference the renamed class.
Is there a way to define a hard references of some kind, so the reference does not get lost when renaming a class? Or any other suggestions to keep references from getting lost.
I've also tried including a meta file with a guid in the dll, but unity does not seem to take this meta file into account, as it always uses the guid of the dll together with the generated fileId.
Unity can't automagickaly find out you have renamed some class inside the DLL. That's true for any form of project : if you depend on some DLL, and classes changes in the DLL, there is no indication of rename.
The best way to link them is adding your Unity project in the solution, and place a dependance between Unity project and the another. Then maybe the refactor tool will suggest you the rename in the Unity project.
Here is a really good tool to find and replace missing scripts, which i assume is the error you are getting.
http://daikonforge.com/forums/resources/fix-missing-scripts.3/
It comes with the source code once you unpack the Unity3d Package, so you can customize it to your needs.
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 just got a new PC (Win 7) with VS 2010 (same version as my old PC). I got a VB.NET solution from source control that contains two projects. One of the projects builds fine. The other project flags every non-MS Imports statement with:
Namespace or type specified in the Imports &1 doesn't contain any public members or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
The ironic thing is that the working project within the same solution references all the same DLL's. I've removed and re-added the DLL's so I know they're there, and I can expand them in Object Browser, so I know they contain public methods.
I've ran out of ideas of things to try. Can someone throw me a bone, plz?
I had the same problem which I fixed by changing the Project Properties->Compile->Advanced Compile Options->Target Framework value from .Net Framework 4.0 Client Profile to .Net Framework 4.0
I had this happen. For me, the new DLL was targeting Dot Net 4.5, while the project which referenced it was only targeting 4.0. Switching the new dll to match fixed the issue.
I've had a similar issue as this before. In my case the problem was that the dll's were located on a network share drive (which in my system showed as q:) so when I referenced them the file path was q:\folder structure\file.dll. Upon switching machines, my system no longer referenced that share drive as q:\ but by another drive letter, causing my program to error out similarly.
In my case, I was able to correct this issue and prevent it from happening again by changing the way I referenced the dll from the drive letter it was assigned by my local system to the network path (\SERVER NAME\Drive Letter\file path\file.dll).
I was experiencing the same issue. The DLL I was referencing was built in framework 3.5. The project I was referencing the DLL was being built in 2.0. I switched the referring project to 3.5 and it built perfectly.
I had this problem with projects which were referencing the same version of the framework. I solved it with the following steps.
Remove reference to DLL
Clean and ReBuild DLL
Clean and ReBuild Project
ReAdd Reference.
This happened to me in a Visual Studio 2019 VB project with System.Data.SqlClient . Since the Import of System.Data.SqlClient was failing, all of my Sql classes used in declarations on the page -- SqlConnection, SqlCommand, SqlDataReader -- were undefined.
To fix it, I just had to use a full reference to System.Data.SqlClient.SqlConnection when declaring my very first variable for one of those classes on the page:
Using conn As System.Data.SqlClient.SqlConnection = New SqlConnection(GetConnectionString())
By changing just that first declaration on the page, it fixed the compilation error on the Imports line and all subsequent declarations on the page. (Even stranger, after building the project once like that, I was able to revert the declaration back to just referencing SqlConnection, and the Import worked and the page is compiling fine. So it may have been a temporary issue unrelated to my temporary fix)
I had already fixed this problem once I got to the point of googling this, and all I had to do was delete and re-add the reference in the solution explorer
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.