0

I have used multiple threads, namely this one to create a reference to the visualbasic dll. But to do this you need to have the "Assemblies" tab in the Reference manager window.

When I try to create a reference to this dll file, the "Assemblies" tab doesn't even show up! This is what I mean.

What do I do to get it to show up, I am not a absolute mastermind when it comes to coding so I'd appreciate it if you could simply the problem and answer. Is it the fact that I don't have a "References" folder in my solution (I've never had one from the start)?

Thanks.

EDIT: Fixed! @Jimi and @jmcilhinney said changing from .NET Core to .NET Framework would fix the issue, it did.

batv1
  • 131
  • 7
  • 1
    Why are you trying to add a reference to that DLL to a VB project in the first place? All VB projects already reference that library by default. If yours is not a VB project then this is not a VB question, so why is it tagged VB.NET? Also, your image link is broken. – jmcilhinney Jul 20 '20 at 09:08
  • Maybe you want to build a .Net Framework Project instead of a .Net Core one. – Jimi Jul 20 '20 at 09:48
  • @Jimi Because I want to play sounds in the console window which requires the [dll](https://learn.microsoft.com/en-us/dotnet/visual-basic/developing-apps/programming/computer-resources/playing-sounds). VB won't recognise the line of code because "it is not a member of [my project name]" [see here](https://stackoverflow.com/questions/62952660/trying-to-play-sounds-in-console-application-vb-net/62952953?noredirect=1#comment111326245_62952953). Also, I fixed the link. – batv1 Jul 20 '20 at 09:48
  • Are you sure you want to build a .Net Core Project and not a .Net Framework Project? – Jimi Jul 20 '20 at 09:53
  • I can see the video via that link now. You have definitely created a .NET Core project. Get rid of it and create a .NET Framework project and that DLL will be referenced by default. – jmcilhinney Jul 20 '20 at 09:54
  • @Jimi I'm honestly not sure the difference so I can't say I'm sure. – batv1 Jul 20 '20 at 09:55
  • Well, I think you already know of at least one difference now :) – Jimi Jul 20 '20 at 09:56
  • @jmcilhinney Ok I see, I'll try that :) , I'm confused about why there are two types of .NET and why one makes it impossible to use the dll reference, I guess it doesn't really matter if my issue gets fixed. – batv1 Jul 20 '20 at 09:59
  • Check [this](https://stackoverflow.com/questions/38063837/whats-the-difference-between-net-core-net-framework-and-xamarin) out as a starting point. – jmcilhinney Jul 20 '20 at 12:35
  • @jmcilhinney I've changed to .NET Framework but now the actual function of the program is broken. It web-scraps from an online Japanese dictionary, when my program was using .Core it displayed the characters fine, but now it displays random jiberish like "ãŸã„". It is important to note that it doesn't display ⍰ (which is caused by the problem of the program not having the right font to display the characters), the problem is the fact that the program doesn't know what the characters are at all, [here](https://imgur.com/yfL3hEQ) is what I mean. Why is this happening? And do you know a fix? – batv1 Jul 20 '20 at 18:15
  • You need to specify what tools you're using. If WebClient is one of these tools, see here: [Kanji characters from WebClient html different from actual Kanji in website](https://stackoverflow.com/a/49848091/7444103) -- I don't know why I'm notified of this comment, you didn't actually ping me. Anyway... – Jimi Jul 20 '20 at 18:56
  • @Jimi OMG, thank you so much, I don't think you know how happy I am! Even though you didn't come up with the solution you still pointed me in the right direction! I am really grateful, once again thanks! :) – batv1 Jul 20 '20 at 19:06
  • For anyone wondering, Adding the following line of code worked `client.Encoding = System.Text.Encoding.UTF8` (only works if you use WebClient) – batv1 Jul 20 '20 at 19:08
  • Hmm, you didn't read the notes there thoroughly enough. In your case, it happens that the Site you're scrapping uses UTF-8, but it may not be (as in that question). The .Net Framework WebClient has a major flaw (well, not exactly, it's about the reason it was built for), it doesn't consider the Response encoding, it uses the Request encoding (set on the Client side). Thus, that code uses reflection to extract the **real** encoding, as defined by the remote resource, reading that value from the underlying WebRespose. A custom WebClient could do the same thing, in a more *permanently* manner. – Jimi Jul 20 '20 at 19:18
  • Yes, I understand. – batv1 Jul 20 '20 at 19:46

0 Answers0