Incorrect reference PcapDotNet.?.dll - visual-studio

Hello
I try to use PcapDotNet dll but I can't add reference to my project.
It doesn't matter which dll it is. PcapDotNet.Core.dll, PcapDotNet.Base.dll etc.
I have yellow exclamation mark near this reference and can't use any methods from this dll.
Ofc "using PcapDotNet.Core;" is underlined too and compiler shows me: "The type or namespace name 'Core' does not exist in the namespace 'PcapDotNet' (are you missing an assembly reference?)"
Different dll I can add normally.
Any ideas?

I rubbed my crystal ball and it said: "you downloaded this from the Codeplex site and you are using a Visual Studio edition earlier than 2010."
It's usually pretty reliable when it gets that explicit, I'll work from the assumption that it is accurate. If you are not ready to upgrade to VS2010 then you'll need the 0.6.0 version, as documented on the landing page. The 0.6.0 download is listed in the upper right box, this is the link.

Related

Dotnetnuke 8 module development error in visual studio 2013

I have successfully installed DNN 8 and all configuration.
i am also referring video to develop module in visual studio.
https://www.youtube.com/watch?v=AKCYRPuoXF4
when i am trying to build the project then
error comes like:
Error 17 The type or namespace name 'DotNetNuke' could not be found
(are you missing a using directive or an assembly
reference?) C:\websites\dnndev.me\DesktopModules\MyDNNModule\MyDNNModuleModuleSettingsBase.cs 13 7 MyDNNModule
Please help to solve that.
thank you in advance.
Working with DNN8, sometimes I get a set of errors with message
The type or namespace name 'DotNetNuke' could not be found (are you
missing a using directive or an assembly reference?)
, probably 10 or 15 of them, and all located on top of one ascx file. (My dotnetnuke.dll is correctly placed in DNN's bin folder). Taking a better look (scroll down!), I can see that - except them - there are some more error messages (maybe just one of them), and that those additional errors are perfectly clear and logical. So I correct my source code in order to avoid those additional messages, and when I do that - those problematic messages also disappear!
In my case it took me a while to find the solution to this problem, since it only got triggered when I made a change to the View.ascx file.
You need the Visual Studio project to target framework to 4.5 instead of 4.5.1.
I got this solution from here.
Make sure to add a Reference to dotnetnuke.dll in the c:\websites\dnndev.me\bin folder
I honestly haven't done anything with DNN 8 CTP yet, I would stick with 7.4.1 until 8 is official released.

VS2010 to VS2012 ToolWindow XAML Reference VsBrushes

So I thought I'd run this out there, and see if I was missing something idiotic.
I developed a small my-use-only VSIX extension, and in one of my toolwindows, I'm using the code to set the foreground/background color:
Foreground="{DynamicResource {x:Static vsfx:VsBrushes.ToolWindowTextKey}}"
Background="{DynamicResource {x:Static vsfx:VsBrushes.ToolboxBackgroundKey}}"
The vsfx: namespace is referenced as:
xmlns:vsfx="clr-namespace:Microsoft.VisualStudio.Shell;assembly=Microsoft.VisualStudio.Shell.10.0"
I see the 10.0 referenced there, and for me, that's expected as I originally did this up in VS2010. Now that my work has made me upgrade to VS2012, the XAML designer is giving me the following error on those two SynamicResources. The error reads 'The resource {x:Static vsfx:VsBrushes.ToolWindowTextKey} could not be resolved.' and like for the second one.
Now, note that the project still builds and runs, and can be loaded into VS2012. However, the colors are all off (standard, don't match the theme that VS is set to.)
Any thoughts on what to check or look for?
Cheers -
Mike.
I ran into the same question as you guys do, and found out the follow facts:
[VsBrushes/VsBrush] v.s. [EnviromentColors]:
VsBrushes and VsBrush are basically the same thing, supported in VS2010/2012/2013;
EnviornmentColors is only in VS2012/2013, not supported in VS2010;
EnvironmentColors is still envolving, more colors will be added in for new themes; VsBrushes/VsBrush are relatively static.
[VsBrushes] v.s. [VsBrush]:
Good thing about “VsBrushes” is that it checks whether a specific color name exists during building.
Bad thing about “VsBrushes” is that is has to specify the VS namespace and assembly version in the XAML file head, which is inconvenient. (e.g. xmlns:vsfx="clr-namespace:Microsoft.VisualStudio.Shell;assembly=Microsoft.VisualStudio.Shell.10.0")
Thanks.
Use EnvironmentColors class as it's stated here:
http://msdn.microsoft.com/en-us/library/vstudio/jj991932.aspx

PagedCollectionView not found in Silverlight 4 (again? yes)

I know this will sound quite redundant, but sadly, no answer I have found to this problem online helped me.
I am running Visual Studio 2010, and using the Silverlight 4 SDK (April 2011 version) for my project. (set in the properties, I double-checked)
I did add "using System.Windows.Data;" at the beginning of my .cs file.
Yet, the compiler still gives me "not found" errors concerning my calls to PagedCollectionView.
When I type "System.Windows.Data.", the completion gives me plenty of suggestions, but no "PagedCollectionView"... the first suggestion I get starting with P is "PropertyGroupDescription".
Has this useful tool just been erased out of the surface of the Earth?
Thanks
You need to add a reference to assembly System.Windows.Data for PagedCollectionView.
The namespace System.Windows.Data is used in multiple assemblies for example System.Windows that contains PropertyGroupDescription

Object Browser, Fully Qualified Assembly Name, and Config Files

I needed to add a System class to my config file, and found it would not work unless given a fully qualified assembly name. Ok, no worries, I'll simply look that up.
Uh oh.
I expected the Object Browser in Visual Studio to have that information. That would be too obvious. It was not there. I started to search for how to get this information, and found MSDN for .net 4 telling me to use Mscorcfg.msc, except MSDN also says that Mscorcfg.msc "has been removed from .NET 4 and later versions." This is not an auspicious beginning.
Of course there are answers that explain how to do it programmatically; I already know how to do that, and that isn't the point. I don't want to write my own program just to find the publickeytoken of an assembly I want to put into my config file.
I then find an article suggesting "sn.exe" for files not in the GAC, and an answer suggesting the gacutil for everything else. A few others suggest using RedGate's Reflector. Sigh.
I'm trying to figure out why such a common activity - inserting a fully qualified assembly name into a config file - requires such a "Visual Studio 6 era" hokey-pokey firedrill to get such a simple thing done. So we come full circle: Why on EARTH does the object browser not simply provide this information? Please tell me there is a simple VS configuration option I've missed, that explains how this is done.
To be clear, yes, I have obtained the FQAN I was seeking. I just don't think resorting to GACUTIL.exe, after googling for a while in disbelief, should be the right answer. What am I missing?

Assembly Not Being Recognized

I built a VB Windows Forms application a while back using VS05 (or VS08? Not exactly sure) that I've recently converted to use VS10. I reference a .dll called ExcelPackage (another article, usage) so that I can create/manipulate Excel docs serverside. This app has worked fine on my old computer (PC/Vista) for a number of years. However, I have tried to move it to my new computer (PC/Win7 64-bit), and I can't get it to recognize the ExcelPackage .dll.
I have tried recompiling the .dll in VS10 and dropping the new .dll in my bin folder and re-referencing it. When I do this, before I try building, all my errors go away and I am actually able to navigate the class using VS10's built in ability (mouse over Imports OfficeOpenXml and you get a dropdown arrow that allows you to go through the classes). After I build, I get a green squiggly under my Imports OfficeOpenXml statement (can't find the reference).
I did some research and discovered that the .dll containing System.IO.Packaging has been moved around in .NET 3.0 and even re-referenced the new .dll, rebuilt, re-added, re-referenced, still no dice.
Am I missing something, or how do I get my application to recognize this assembly so that I can compile and continue working?
Thanks.
I don't see anything special about that project. Do note that the solution and project need to be converted. When that happens, you'll end up targeting the .NET 2.0 framework. That won't work out well, it has an assembly reference to WindowsBase, a 3.0 assembly. Make sure you update the target.

Resources