In VS2010 and .NET 4.0, I see the shortcuts in intellisense for adding contracts to my code (Eg cr, crr) but when I tab to add these in, the code (Such as Contract.Requires) does not have the valid assembly so there is no intellisense (The type can't be found basically).
How exactly do I get up and running with code contracts?
EDIT: All the methods exist in System.Diagnostics.Contracts, but I thought that I would be using attributes throughout? Also, there are so many different .dlls for the contracts available!
Thanks
The assembly is just mscorlib - and Contract is in the System.Diagnostics.Contracts namespace.
<plug>
For some more information about Code Contracts, you could buy the second edition of C# in Depth and read chapter 15. (That chapter was available free, but isn't now I'm afraid.)
</plug>
Or of course you could read the docs too, as they're pretty good :)
If you find you're missing the System.Diagnostics.Contracts namespace, it's worth checking that you really are targeting .NET 4 - if you create a .NET 3.5 project in VS2010, that won't have Code Contracts available (without adding an explicit assembly reference, anyway).
Related
I'm trying to track down an issue with MVC so I thought I would step into the ASP .NET Core source code. I've unchecked "Enable Just My Code" and I've checked "Enable .NET Framework source stepping" (although I guess that's not necessary). I've also checked "Enable source server support" and enabled the Microsoft symbol server.
I step into this line
app.UseMvc();
and eventually I get to this code in MvcApplicationBuilderExtensions.cs.
VerifyMvcIsRegistered(app);
var options = app.ApplicationServices.GetRequiredService<IOptions<MvcOptions>>();
if (options.Value.EnableEndpointRouting)
{
Stepping through this code the program counter starts to jump around and I receive an error that several of the local variables cannot obtain the value because it is not available or it's been optimized away. I assume this is because the source file and the symbol files don't match.
I'm running this on Visual Studio 2019. It's .net Core 2.2.203. I've deleted the symbol cache and the SourceServer cache. I'm trying to figure out what I've done wrong in my code and exactly why.
Actually, I've tried to debug .NET source code several times over the past several years and I always have the same issue. None of the online help seems to have an answer. Am I doing something wrong or is this just unreliable?
The message is accurate and explains exactly what happens. It has nothing to do with mismatched symbols.
The (non) problem as the message explains is that the IL has been optimized during compilation, those variables no longer exist. A Release build performs a lot of optimizations that usually end up eliminating parts of the code that aren't needed.
Functions can and quite often are inlined. A variable may be replaced by a register for example. A loop may be eliminated entirely. When that code runs the variables or functions are no longer there so they can't be displayed.
Debug symbols can still be generated in a Release build. They'll reflect the IL generated for a release build though. One would need assemblies compiled in a Debug configuration to get IL that matched the source without any optimizations.
That's true for the .NET Core runtime, our own code when run a Release build and all NuGet packages.
If you want to debug .NET Core source code you can download it from github (https://github.com/dotnet/corefx). It's very easy to debug, like your own project.
There is very good video, where explains how .NET Core MVC request life cycle works (https://app.pluralsight.com/library/courses/aspnet-core-mvc-request-life-cycle/table-of-contents), maybe there you can find information which you need.
P.S. you can get 3 months free in pluralsight with microsoft account.
I have a VS 2013 solution with one VB.NET ASP.NET project which references several c# class library projects (not DLLs) within the same solution. I made lots of changes to logic within some of the method overloads in one of the c# projects. Since the VB.NET project uses these overloads extensively, I want to see how many places these methods are referenced. I go to the c# project that contains the changes, right-click the overload I want, and select Find All References, but it only shows me the references in the c# projects. However, when I go to one of those methods in the VB.NET project, it finds all the references within the VB.NET project as well as the method declarations in the c# project.
I could do a solution-wide text search for the method name, but this method name is used multiple times because it's overloaded. Therefore, I want to search for a particular overloaded method signature, not the method name.
Is this a known shortcoming of VS 2013? Something else I've also noticed that I've noticed is that selecting Go To Reference from within a VB.NET project on a method that's declared in a c# project will take you to the object browser rather than directly to the method definition in the source project itself.
This is an old problem, there are many bug feedback reports for it on Microsoft's feedback site. The canonical one is probably this one. Quoting Dustin Campbell's response:
The general problem is that C# and Visual Basic do not share any common infrastructure with regard to the symbol tables that are used for features like Find All References, Go to Definition or Rename. So, such features don't work between multiple languages. That said, we are looking at ways to change this in the future, but the work required is very substantial.
Annotating a bit, the C# and VB.NET IDEs look similar at the surface but they are very different under the hood. Part of that is them being supported by distinct groups within Microsoft, a survival strategy for any software company, big groups don't work. But above all history plays a strong role in this, Visual Basic had strong IDE support for a very long time. They did not throw away that work when they moved to VB.NET, not in the least because they had to support all previous IDE features so not to alienate their existing customer base. The C# team got a fresh start without that baggage, they started from scratch. Inevitably the internals between them, like the IntelliSense symbol tables, are drastically different.
Tackling the "common infrastructure" problem was not forgotten, the Roslyn project was the instrumental step. It took a very long time to get finished but it is ready to go today. Integrated into VS2015. Whether it actually solves this problem is something I don't know yet, I will in a couple of months. Maybe somebody that has the RC version can confirm. They did create two versions of Roslyn, one for C# and another for VB.NET. Uh-oh.
I am attempting to add a Fakes assembly (in Visual Studio 2012 Ultimate) for an library that I reference in my code so that I can test independently of the libraries implementation. The the problem I'm having is that when I right click the referenced assembly and click "Add Fakes Assembly" I receive the message:
"Assembly not supported
Fakes does not support this assembly."
I've tried Googling this message but get 0 results if I put it in quotes and nothing relevant if I don't. I thought this was quite strange as you would expect someone else to have run into this issue at some point but anyway...
After giving up on searching for the message I tried searching for somewhere that might tell me what types of assembly Microsoft Fakes does support but this also proved fruitless.
I guess my question is: Does anyone know what types of assembly Microsoft Fakes does/doesn't support.
I've included some information about the assembly I'm referencing in case anyone knows why this one in particular isn't supported:
-Its a COM Interop assembly.
-Its an ActiveX component.
-It isn't strongly named.
Any leads at all would be greatly appreciated.
To be honest, the things you mentioned probably aren't the problem. It's entirely possible to fake Excel interop classes, for instance (not that you can use them!).
But if you take a look at what thing's don't support fakes, such as sealed classes, which don't allow stubs because stubs require inheritance, and some reflection classes which restrict shims, it's clear that some classes will have neither, thereby allowing a dll to have no fakeable components. Not much you can do there.
Additionally, Shims cannot be used on all types from the .NET base class library mscorlib and System. says MSDN.
I have to maintain an old VB 6 ActiveX DLL called by another third-party program for which I have no sources. This DLL works and compiles fine against the API of said program for about 6 years and 3 major versions.
But now when I try to compile the DLL against a new major version the mentioned error occurs. It seems the error occurs before "my" code is called so there´s no use debugging or logging. The only remedy was to compile w/o binary compatibility which is no real option. My Google search turned up quite some people with the same problem but no solution.
Does anybody here know how to fix this issue ?
I finally figure out how to diagnose VB6 error 32801 in a systemic way.
My theory is When the VB6 compiler is creating a project or binary compatible library, the compiler decompiles the type information from the referenced library. Error 32801 occurs the source code's type information is not the same as the referenced library.
There is a tool called OLEView. This tool can decompile the COM type information into an IDL text. What I do is decompile the referenced library in to IDL and take the last good build of the failing library. Most times it is a build server version but the build does not work on a developer workstation. Decompile the last good build. Use a text comparison tool, like WINMerge, and find the differences between the type libraries. The differences make it easy to track down the problem.
Depending on the difference will determine how to correct. Mitigation can be done by either correcting the reference DLL, or by source code correction, or source code references.
It sounds like one of the types in the interfaces defined in your new DLL is different from one in the previous DLL. I'm deducing you use types defined in the third party program in your public interfaces of your DLL. It sounds to me like the third party has changed the definition of one of the types but kept the name and GUIDs the same. You could use something like OLE/COM Object viewer to check whether that's true. If it is true then you can complain to the publisher of the 3rd party program. Do you have enough political power to succeed?
Bruce McKinney, the guru who wrote Hardcore Visual Basic 6, ran into the same issue with a structure in a type library, where he changed some of the member types. The only fix he could find was (essentially) to break binary compatibility - and that's after some correspondence with the VB6 compiler team, who he knew fairly well. I don't think anyone else could do better.
There is a discussion about this error on devx.com that seems to indicate that the problem stemmed from Microsoft's Scripting Runtime (scrrun.dll).
FileSystemObject compatibility Unexpected error (32810)
Does your DLL reference that library? If so, can you remove the reference (e.g., replace FileSystemObject functionality with intrinsic VB file handling functions and/or API calls).
Are any of the files associated with the core project being compiled marked as Read-Only (i.e. not checked out of SourceSafe or similar repository)?
*.exp
*.vbw
*.lib
---------------------------
Microsoft Visual Basic
---------------------------
Unexpected error (32810)
---------------------------
OK Помощ
---------------------------
This the message I was getting trying to reference in VBIDE an old OCX that has been recompiled recently.
After somewhat long research the offending lines of code causing this error appeared to be
Property Get MouseActivate() As BookmarkEnum
Just changed this to
Property Get MouseActivate() As Boolean
. . . and the error was gone.
BookmarkEnum is an enum from ADO. Our build server is Server 2003 and my dev machine is Win10. The project references ADO 2.8 but apparently this typelib has some differences on Server 2003 vs Win10
This is the text from MSDN comment: "According to the book ATL Internals (2ed) the use of attributes is deprecated and should not be used in new ATL projects."
But WHY?!!
In ATL these attributes were a compiler trick. They were not a core part of the platform like attributes in C#. They were also more confusing to debug than macros's and the method of dumping generated attribute code was a hassle.
I suspect another issue is likely to have been C++ compiler compatibility and standards-adherence. Attributes didn't make for more beautiful C++ code, and perhaps this syntax may be used in a future version of a real C++ standard.
Appendix D of the book goes into this.
Attributed ATL requires compiler extensions, and the problems encountered include
debugging either code generated by the attribute or the interaction between the attribute and your code
no control over the code generated
bugs, especially around connection points