Currently doing a VB 6.0 project,after registering few ocx files added the same in the projects initially and removed it later and done the above steps from a different location with the same ocx files.Now i am having two controls with same name present in the component dialog, want remove the unwanted reference how to do it.please help me out
Usually the components appear after adding a reference throught Project->References. You can surely google wich dll is associated with which ocx.
I got a similar issue and after a few hours of digging in, I found out a solution. You need to go to Regedit and find by name your dll. Visual Basic 6.0 IDE registers it in the registry so it's not possible to remove it from IDE UI. After removing key in Regedit and restarting IDE, unwanted reference disappeared.
Related
I'm new to vb 6.0 this is an existing project.
Suddenly the hardisk was corrupt so i take backup form sever and run in new hard disk and when the project run there is no issue but when ctrl+F5 (compile) OR build exe get this error given below.
Is there any reference missing or need to add
You need to add a component Microsoft Windows Common Controls 6.0 (SP6).
Go to Projects -> Components (Ctrl+ T) and check the checkbox for it.
Once this is added, you will also see extra components in the available GUI elements.
Regarding the screenshot it looks like you have referenced both OCX Libraries
Microsoft Windows Common Controls 5.0 (SP2) - comctl32.ocx
Microsoft Windows Common Controls 6.0 (SP6) - mscomctl.ocx
You can only use the ListSubItems collection with the Common Controls 6.0. If you want't to check which one is in use, you can open the .frm file in a TextEditor and search for the control name.
In front of the name you see either ComctlLib.ListView (5.0) or MSComctlLib.ListView (6.0)
You can also try to change the Library in the TextEditor. It worked with a sample project for me, but I'm not sure if there are properties used in your project that could break after the "switch" to the 6.0 controls.
I installed Unity 2017 with Visual Studio 2017. I am attempting to add an external DLL to the Visual Studio project through the solution explorer. When I right click on References, the "Add Reference" option is completely missing!
I'm trying to use NpgSQL. Hence, the need to add npgsql.dll.
Can anyone give light?
The Add Reference... is in a different place in this case.
Things to do in Unity:
Create a folder named Plugins as a child to your Assets folder. (Assets\Plugins...)
Next copy your DLL to this plugins folder. You can do this using Windows Explorer or just drag it into the folder in the Unity editor, like shown:
Things to do in Visual Studio:
Click on Analyzers in your project as shown below, then click Project from your menu, then navigate to Add Reference...:
Now Browse to your DLL:
And... there it is:
Accepted Brien's answer (Thank you, Brien!).
I'm adding my own answer pertinent to Npgsql.dll, because it's apparently a common problem all over the internet with poor documentation. If you got here from google about Npgsql.dll then read on:
Unity (for some unknown reason) comes bundled with it's own npgsql.dll inside of the application mono/2_0 folder. Some people have reported conflicts with this.
Many of the npgsql.dll versions currently do not work with Unity. Attempting to include them in Unity's assets will cause Unity to throw a Type error. This is what caused me to think that I needed to add the file as a reference in C#. This is why I came here and asked the question about Add Reference. But, with Unity, this was simply wrong on my part.
As far as I can tell, Unity insists on managing all project properties and references for you. Both managed and unmanaged DLLs must be added via Unity assets. Even Visual Studio project properties cannot be changed within Visual Studio for Unity. And if you attempt to edit the .csproj files (for instance to disable compiler warnings), Unity will overwrite the .csproj files completely next time you load your Unity project.
Anyone who has problems getting Npgsql.dll to work in Unity needs to use the proper Unity workflow where you drop npgsql.dll into Unity assets. If you get errors, it's an npgsql.dll version conflict. Try other versions of the dll first.
This gentleman has provided a Unity specific build to resolve a namespace conflict (Just pull the dll from the bin folder on the Github link):
Unity NPGSQL.DLL
Unity 2017 currently allows you to change to .NET 4.6 as an experimental setting. Some people have toyed with using that setting to get newer versions of npgsql.dll to work properly, but they report intermittent results. For now, I solved my problem with Unitynpgsql.dll. It's an older build, so hopefully I won't run into any features I need that it doesn't support. If so, I'll probably just work around them.
To anyone else trying to make npgsql.dll work in Unity: do not despair, just try to resolve the version conflicts. Also here is another relevant recent thread about it:
Barebones Master Server Npgsql.dll Issue - January 2018
The problem
Suddenly, Visual Studio (2015 RC) started throwing error CS7069 in my face a lot. It states
Reference to type '...' claims it is defined in '<assembly>', but it could not be found.
Yet VS's functionality "Goto reference" did function and squigglies weren't consistently present, so I figured something weird was going on.
How I created the problem
It started when I was refactoring/splitting a project. I was moving .cs files from one project to a new one. Types that I moved to the new project couldn't be found anymore by the compilation process of a project that referenced both projects.
What I tried
I verified that the relevant assembly was indeed referenced, present and had the type with public modifier. I rebuilt it, checked version numbers (of target frameworks etc), removed the relevant reference and re-added it, cleaned solutions and projects, checked configuration manager settings, removed all VS's temporary files and whatnot, and I couldn't fix the bug for 4 days. 4 long days, might I add.
Googling didn't result in anything either, so I hope that the next poor fellow who made the same mistake as I did finds this page, as I finally found out what was going on:
I had two projects with identical assembly names...
Renaming the new assembly in its properties menu made all errors vanish.
Fixed bug on Visual Studio 2015.
Go to Tools menu, Options, Debugging, General: Check: "Use the legacy C# and VB expression evaluators"
Try to clean/rebuild the project. It helped me.
Also try to remove all of the *.suo and *.user files in your solution folder
http://blog.galasoft.ch/posts/2014/01/quick-tip-what-to-do-when-visual-studio-freaks-out-and-everything-is-red/
I had this problem and it turned out I had the wrong build configuration selected. The reference projects and the project I was building were not selected for that build configuration. Simple to fix, but not something I looked at for a while.
I am using Visual Studio Professional 2010 and the Team Foundation Server Express (beta). My VS Project (C#.Net / WPF) has been migrated from VS 2008 (without TFS) to VS 2010 (with TFS).
Whenever I apply changes to my code and try to debug my application, I get messages like This breakpoint will not be hit. (in german: Der Haltepunkt wird momentan nicht erreicht. Der Quellcode weist Unterschiede zur Originalversion auf.) and the project is started using the old executable version (the one with the last successful build). No errors occure, the code is OK, but the changes are not applied either.
When I manually cleanup and rebuild my project, everything works quite fine - but there has to be a fix for this issue?
Edit: I just added a new project to my VS solution and checked it in on the TFS Server. Using this new project the problem does not occure. Even when I add the same dependencies I used in the project mentioned above, the debugging and building of the new project works fine without the errors mentioned above.
Maybe this information helps you to lead me to a solution.
It's not clear whether existing answers are not sufficient. I can't know exactly what's causing your problem; but, I can detail some places this potentially comes up.
The first area that I commonly see this is when a project references an assembly directly. You can create a project that creates an assembly. Another project might use that assembly and you can reference by assembly directly (and not add a reference to the "project"). This disconnects VS from really knowing it needs to "build" that referenced assembly first and it will sometimes get out of sync with the debugging symbols (PDB). You can tell if a project has been referenced or an assembly has been referenced in the properties of the reference (expand References in Solution Explorer, right-click a reference, and select Properties). A referenced project will not have a Specific Version property, while an assembly reference will. You can sometimes also tell from Project\Project Dependencies. If you have a reference to an assembly generated by another project but that project isn't a dependency in Project Dependencies, it might be an assembly reference. To fix this, you can usually just delete the reference and add a reference to the project.
I've also find that sometimes breakpoints confuses the debugger. If I have many breakpoints or they've been kicking around a long time, the debugger sometimes does some weird things. If I delete all the existing break points (Debug/Delete all breakpoints) and re-apply them the debugger is usually much happier.
You can find the answer here. The assemblies might be in GAC or a project or some projects need to be rebuild to generate the pdb files again, which are used for debugging. If you don't choose to rebuild it might use the old pdb files.
My guess is that you are putting breaking points somewhere your program can't access them.
Ex:
const int x = 5;
if(this.x == 1)
//do sth <--- breakpoint here
If you are running a mixed mode application (unmanaged native C++ & managed C#), make sure to set Enable unmanaged code debugging in your C# application's Properties window.
You have to rebuild, there isn't an easier way around it.
The program database files (PDB) need to be recreated. You should also have your configuration setting set to debug.
Also the first answer to this question must be of help as well.
This happened to me when I started VS as an admin, and it also happened to me when the project is set to a different architecture than a DLL that I used in this project.
This assembly is in the GAC: Microsoft.SqlServer.Management.RegisteredServers.dll
How can I add a reference to this assembly in Visual Studio?
I can view the file in c:\windows\assembly\
As the others said, most of the time you won't want to do that because it doesn't copy the assembly to your project and it won't deploy with your project. However, if you're like me, and trying to add a reference that all target machines have in their GAC but it's not a .NET Framework assembly:
Open the windows Run dialog (Windows Key + r)
Type C:\Windows\assembly\gac_msil. This is some sort of weird hack that lets you browse your GAC. You can only get to it through the run dialog. Hopefully my spreading this info doesn't eventually cause Microsoft to patch it and block it. (Too paranoid? :P)
Find your assembly and copy its path from the address bar.
Open the Add Reference dialog in Visual Studio and choose the Browse tab.
Paste in the path to your GAC assembly.
I don't know if there's an easier way, but I haven't found it. I also frequently use step 1-3 to place .pdb files with their GAC assemblies to make sure they're not lost when I later need to use Remote Debugger.
Registering assmblies into the GAC does not then place a reference to the assembly in the add references dialog. You still need to reference the assembly by path for your project, the main difference being you do not need to use the copy local option, your app will find it at runtime.
In this particular case, you just need to reference your assembly by path (browse) or if you really want to have it in the add reference dialog there is a registry setting where you can add additional paths.
Note, if you ship your app to someone who does not have this assembly installed you will need to ship it, and in this case you really need to use the SharedManagementObjects.msi redistributable.
I've created a tool which is completely free, that will help you to achieve your goal. Muse VSReferences will allow you to add a Global Assembly Cache reference to the project from Add GAC Reference menu item.
Hope this helps Muse VSExtensions
In VS2010, from the Add Rerences window you can click 'Browse' and navigate to C:\Windows\Assembly and add references to the assemblies that you want. Please note that the files may be grouped under different folders like GAC, GAC_32, GAC_64, GAC_MSIL etc.
In VS, right click your project, select "Add Reference...", and you will see all the namespaces that exist in your GAC. Choose Microsoft.SqlServer.Management.RegisteredServers and click OK, and you should be good to go
EDIT:
That is the way you want to do this most of the time. However, after a bit of poking around I found this issue on MS Connect. MS says it is a known deployment issue, and they don't have a work around. The guy says if he copies the dll from the GAC folder and drops it in his bin, it works.
The only way that worked for me, is by copying the dll into your desktop or something, add reference to it, then delete the dll from your desktop.
Visual Studio will refresh itself, and will finally reference the dll from the GAC on itself.
Assuming you alredy tried to "Add Reference..." as explained above and did not succeed, you can have a look here. They say you have to meet some prerequisites:
- .NET 3.5 SP1
- Windows Installer 4.5
EDIT: According to this post it is a known issue.
And this could be the solution you're looking for :)
May be it's too late to answer, but i found a very simple way to do this(without a hack).
Put your dll in GAC (for 3.5 Drag Drop inside "C:\Windows\assembly\")
GoTo Projects --> Properties
Click Reference Path (for 3.5 it's "C:\Windows\assembly\")
and Build
Hope it helps
The relevant files and references can be found here:
http://msdn.microsoft.com/en-us/library/cc283981.aspx
Note the links off it about implementation/etc.
I found this extension for VS 2013 Vitevic GAC Reference.