I really like the moq mocking framework. I've used it on several projects. Unfortunately, one of my customers is demanding we use VB.Net. Not my preference, but hey, .Net is .Net, right?
I've heard that moq has some trouble with VB. Is this true? Is so, what sorts of trouble? I would expect it to work fine given the language agnostic nature of .Net.
Should I look into using some other mocking framework for use with VB?
The main problem of VB.net with regards to mocking frameworks is that, contrary to C#, VB does not have anonymous methods, only Lambda expressions (no way to declare an anonymous Action delegate).
This severely limits the possibilities.
There is also a known issue with properties with parameters.
Also, the syntax of the language for lambdas does not lead to something as clean as C#, readability-wise (no flames please, I'm a VB user and I miss some C# features every day), and that's partly the attraction for Moq.
The only testing framework I know of that did something with regards to VB is TypeMock. They tried to design something that blends with the VB syntax.
AFAIK Typemock Isolator is the only tool that can fully mock VB.NET. They made an API especially for that.
Related
I've used Teleflex, developerfusion, and SharpDeveloper, and all these, to convert C# to VB, but as most know, there are always errors, and modules left out, and such.
Does anybody know of a good VB editor, preferably freeware, and can handle translated VB and offer suggestions to correct it for you?
Visual Studio underlines things and offers suggestions on some things, but other things it just underlines and leaves you to the guesswork, which doesn't help a non-coder like me.
Non-coders shouldn't be translating C# to VB.
No code translator will take care of everything for you. Even if it works programmatically, there are design patterns and code standards that are different for each language. Hire a programer.
No. And it's not always possible to convert C# to VB. Some features of C# have no equivalent in VB.
Unsafe code (e.g. pointers)
Iterators (yield)
Conversely some features of VB have no equivalent in C#.
Exception filters
XML literals
Why do you need to convert the code anyway? What's the business case?
VB and C# are different langages, so even the best translator in the world will miss some things. The person doing the translation shouldn't be a "non-coder" and should know at least some VB, so when a compile error is shown, he knows what to do with it, or at least knows how to search on the web (or ask on SO) to know how such part of code can be translated to VB.
Although vb.net and C# are both designed around the same .net framework, and consequently feature very similar features that work mostly the same way, many corner cases are handled differently by the two languages. While one could argue ad nauseum about whether a statement like myStruct = new myStructType(someParams) should affect the value of myStruct before the constructor completes (in C#, it does not; in vb.net, it does), and it's probably good to avoid designing code around corner cases, it's doubtful that any translator--much less a freeware one--will detect all of the corner cases and ensure that code which (possibly accidentally) relies upon them will still run correctly.
Is there a comparable and reliable alternative for Rhino Mock library.
I am using Rhino now for MVC ASP.NET project, but am considering (just as plan B) to see if there are any other equivalent alternatives.
RhinoMocks is a very good and powerful Dynamic Mock library. Even though I have been using it for years, I recently switched to Moq.
To my knowledge, RhinoMocks can do everything Moq can do, and perhaps more. The reason I switched is because RhinoMocks has so many different ways you can do the same thing.
To avoid confusion (particularly for colleagues new to mocking in general), I decided to switch to Moq because it has a cleaner API.
Moq is a very good alternative
I advice moq.
There is also NMock which is very old and I believe uses a lot of magic strings. TypeMock Isolator can do way more (including mock DateTime.Now) but costs money and tends to be used more in hard-core legacy application mocking so it can encourage poor discipline.
Is there an OR/M (object relational mapper) that can be used in Classic ASP? Even a simplified class object would be a great help in handling simple CRUD tasks.
Yes I know ASP.NET has many and I use a few of them for ASP.NET sites. However this is a legacy e-commerce site that uses ASP/VBScript and a total rewrite it not a possibility.
You could use .net through COM Interop, and do your ORM in .net. Another option would be to use Code Smith, or MyGeneration and generate VB6 classes.
Here's some VB6 ORM I have not used or researched any of these:
http://www.sparxsystems.com.au/products/ea/features.html
If I find anymore Ill update
There is nothing stopping you from using C# or VB.Net and COM Interop to create a DLL that could be read by your classic ASP page. We have done that several times.
MSDN has two good tutorials on COM Interop.
Try my project called Clapper. Its available on Github. https://github.com/jeremychild/Clapper
I also created a framework, but not is so strong than some frameworks said above,
is a simple but very useful framework and helped me a lot.
It's here:
https://github.com/FelipeNathan/asp-orm
and it's in portuguese
I think IMVHO that ORM is a good choice for small projects but I prefer the easy and direct ODBC connections for larger ones.
All the (good) features of the ORMs can be provided by good RDBMS like Oracle or SQL Server.
What's the best mocking framework syntax-wise and capability-wise ?
My problem: Most mocking frameworks use lambda expressions now, which are really ugly to write in VB.NET, so is there any framework that has nice syntax without lambdas or has fluent syntax that doesn't need lambdas?
I think capability wise Typemock is the best framework for .Net, instead of working within the runtime it hooks into the CLR and can intercept about any call. This enables you to mock and test anything you want. Some people think it's too powerful. It allows you to test anything while usually the fact that you can't test something is a good warning that there's something wrong with your design. Also it's not free.
I mainly use Rhino Mocks. It has a really readable syntax, especially the new AAA syntax. Moq is quite new and should be good too, syntax wise. Although I haven't tested it yet.
rhino mocks.
But you could have trouble with the new lambda-expression syntax (especially when setting expectations on subs) so either use the new syntax or be prepared to work around it.
Typemock's VB APIs are very simple to use, and it has all kinds of functionality like faking Shared functions.
FYI, Isolator has VB.NET specific API so you should be able to use it easily:
http://www.typemock.com/vbpage.php
However, it is a commercial product.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. What is "My" used for?
The purpose of My, as I understand it, is to be an easy shortcut to certain API tasks that are common but hard-to-find or hard-to-use. You probably shouldn't completely subsume your framework under My. (For one thing, C# people using your framework may get grouchy.)
Instead, you should design it as a normal framework. When you're finished, make a list of some common tasks that people might want to use your framework for. See whether any of those could be useful to have under My, especially where there are classes or methods that can be used in a number of ways, but they have one or two really common usages that can be abbreviated with My.
This article shows how to extend My, and it has a section at the end that describes a few design guidelines to follow: Simplify Common Tasks by Customizing the My Namespace
As to your main question, when coding in VB .NET, I use My as often as I can. It reduces a number of operations to one line of code.
I really like the "My" Namespace in VB.NET and I always use it in my WindowsForms applications, because it is very intuitive.
I use primarily these categories:
My.Computer: primarily for file system and network purposes
My.Application: Version number, current directory
My.Resources: Access to resources used by the application residing in resource files in a strongly typed manner.
My.Settings: very handy
I think, if your extensions for My of your framework fit well, then many VB.NET programmers would appreciate them.
I've used My in my VB.NET projects, and I don't feel guilty about it. I am primarily a C# guy, but until I transitioned my company to C#, we were a VB shop. In my mind, the My namespace is a nice piece of syntactic sugar. Just as I'm not embarrassed to use C#'s coalesce operator and other sugar, I'm not embarrassed to use VB's sugar, either. (To an extent; I won't use the classic VB functions that .NET still exposes.)
That said, never put anything in that namespace. It's Microsoft's namespace, and just as you wouldn't put anything under System nor Microsoft, don't put anything under My. It will cause confusion later on -- if not for you, then for others who maintain your code. Create your own namespace for your own code.
We do use it in some code, but hesitantly so. It's true that My often helps make code more readable. For example, the Environment.SpecialFolder enumeration curiously lacks a Temp member, whereas My.Computer.FileSystem.SpecialDirectories has one (Path.GetTempPath() will do as well, but is hardly intuitive compared to other special folders).
But My is only beneficial in such cases because the existing APIs are badly-designed, not because My is inherently better. Like JAGregory, I strongly suggest one avoids extending My — or any other kind of global namespace, variable, etc. — whenever possible. The idea just doesn't fit a clean OOP architecture.
I never use the My namespace (I'm a C# developer), but my VB co-worker doesn't as well. I found the My members not necessary, because in many cases, they're counter-intuitive for me, e.g. in my opinion opening a file has something to do with IO (hence System.IO.File) and not with my computer (My.Computer.FileSystem). They always seem so scattered and bunched together.
It's just some re-roll of functionality that is already available otherwise, from all languages. And I don't like depending on Microsoft.VisualBasic.dll when I'm developing for .NET - I always prefer System.*.
And then, it's always kind of limited. I see VB developers struggle with their app when they can't find something in the My namespace, because they can't imagine that you can use something in the System namespace. That of course is not a problem of the My namespace itself.
I mainly use C# and Boo, but when I do use VB.NET I use My namespace quite often. I dont see any reason to not simplify coding. It still retains its readability.
I've only used it from a user perspective, I've never plugged anything into it. I consider the My namespace to be some highly reliable, platform-provided, global helper mechanisms. Officially sanctioned shortcuts, really. I might be surprised to see external user or third-party code in there.
As such, I'd encourage a vb framework to define its own appropriately-named namespace instead of latching on to the existing My namespace. Such a framework shouldn't have that "global" feel to it.
Never used it so far, although I've never actually looked into it either.
I wouldn't advise putting anything into the My namespace yourself, it's much more clear just to lay it out like you would if it were a non-VB framework.
Love the My! Anything that helps me get the job done faster, and provides code for solutions that I don't have to write, the better!
I use My.Settings and My.Computer often while programming in VB.NET. I particularly enjoy My.Settings as an alternative to using ConfigurationManager.AppSettings when it is appropriate.
I agree with John Rudy about the use of My. It is syntactic sugar that makes life a little more readable.
I don't use it a lot.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?
If it fits, by all means, use it. Since you didn't offer any further information about your framework it's hard to say. I wouldn't put general-purpose stuff into the My namespace (such as the My.Computer stuff) because there isn't really any advantage to putting it there. However, application-centered helpers fit in well.