Here are three popular tutorials on .Net Framework by Stephen Walther.
Very good tutorials on three major frameworks.
Some C++, C#, .Net, windows service, GIS thoughts posted by me. 有度量去容忍那些不能改变的事,有勇气去改变那些可能改变的事,有智慧去区分上述两件事。
Here are three popular tutorials on .Net Framework by Stephen Walther.
Very good tutorials on three major frameworks.
I have been using NUnit/MbUnit/VSTest to develop my tests for a while, but I don’t use mock frameworks too much. I have been reading some blog posts , but didn’t spend too much time digging into those frameworks too much. To effectively use those mock frameworks such as Rhino.Mocks and moq , you have to write your code in a TDD/BDD friendly way. Unfortunately, most of my projects are not designed this way, so I have to manually setup those stubs.
I started to look into the Asp.Net mvc framework lately and think it’s good opportunity to look into those frameworks because Asp.Net will definitely give those frameworks a push. If you download the Northwind example from here, you will find the example uses the moq framework.
Martin Fowler wrote a very good article on this topic. I belong to the classic testers in his definitions.
Stephen Walther wrote a very good article here , and he provided a lot of background information regarding the Moq framework. His summary of the previous article is insightful.
In this paper, Fowler makes several distinctions. First, he distinguishes a stub from a mock. According to Fowler -- who uses Meszaros’ definitions here – stubs “provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.” Mocks, on the other hand, are “objects pre-programmed with expectations which form a specification of the calls they are expected to receive”.
This distinction between stubs and mocks leads Fowler to distinguish between state verification and behavior verification. Stubs are most often used when performing state verification. When performing state verification, you are interested in determining whether a certain condition is true or false at the end of a test. Mocks, on the other hand, are most often used when performing behavior verification. When performing behavior verification, you are interested in how the mock objects interact. For example, you want to know whether a not a certain method was called on one mock object after a method was called on another mock object.
Fowler makes a final distinction between classical TDD and mockist TDD. This final distinction concerns the “philosophy to the way testing and design play together”. A classical TDDer tends to use stubs and state verification. According to Fowler, the “classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing.” A mockist TDDer, on the other hand, almost always uses mocks and behavior verification. A mockist TDDer “will always use a mock for any object with interesting behavior.”
I find it very interesting to read the history of moq from its designer kzu, he created the framework initially because he is not satisfied with the other existing frameworks, however, he has to add a lot of other features into his framework such as VerifyAll. You can find a lot of interesting discussion from the evolving history of moq. Personally, I don’t see moq provides much more than Rhino Mocks. I probably reference both in my project.
Like the Windows functions, the C run-time library offers one set of functions to manipulate ANSI characters and strings and another set of functions to manipulate Unicode characters and strings. However, unlike Windows, the ANSI functions do the work; they do not translate the strings to Unicode and then call the Unicode version of the functions internally. And, of course, the Unicode versions do the work themselves too; they do not internally call the ANSI versions.
An example of a C run-time function that returns the length of an ANSI string is strlen, and an example of an equivalent C run-time function that returns the length of a Unicode string is wcslen.
Both of these functions are prototyped in String.h. To write source code that can be compiled for either ANSI or Unicode, you must also include TChar.h, which defines the following macro:
#ifdef _UNICODE
#define _tcslen wcslen
#else
#define _tcslen strlen
#endif
Now, in your code, you should call _tcslen. If _UNICODE is defined, it expands to wcslen; otherwise, it expands to strlen. By default, when you create a new C++ project in Visual Studio, _UNICODE is defined (just like UNICODE is defined). The C run-time library always prefixes identifiers that are not part of the C++ standard with underscores, while the Windows team does not do this. So, in your applications you'll want to make sure that both UNICODE and _UNICODE are defined or that neither is defined. Appendix A, "The Build Environment," will describe the details of the CmnHdr.h header file used by all the code samples of this book to avoid this kind of problem.
How do you organize c++ header file with template. Here is a good explanation from C++ Templates: The Complete Guide.
There are several ways to organize template source code. This section presents the most popular approach as of the time of this writing: the inclusion model.
Most C and C++ programmers organize their nontemplate code largely as follows:
Classes and other types are entirely placed in header files. Typically, this is a file with a .hpp (or .H, .h, .hh, .hxx) filename extension.
For global variables and (noninline) functions, only a declaration is put in a header file, and the definition goes into a so-called dot-C file. Typically, this is a file with a .cpp (or .C, .c, .cc, or .hxx) filename extension.
This works well: It makes the needed type definition easily available throughout the program and avoids duplicate definition errors on variables and functions from the linker.
With these conventions in mind, a common error about which beginning template programmers complain is illustrated by the following (erroneous) little program. As usual for "ordinary code," we declare the template in a header file:
// basics/myfirst.hpp
#ifndef MYFIRST_HPP
#define MYFIRST_HPP
// declaration of template
template <typename T>
void print_typeof (T const&);
#endif // MYFIRST_HPP
print_typeof() is the declaration of a simple auxiliary function that prints some type information. The implementation of the function is placed in a dot-C file:
// basics/myfirst.cpp
#include <iostream>
#include <typeinfo>
#include "myfirst.hpp"
// implementation/definition of template
template <typename T>
void print_typeof (T const& x)
{
std::cout << typeid(x).name() << std::endl;
}
The example uses the typeid operator to print a string that describes the type of the expression passed to it (see Section 5.6 on page 58).
Finally, we use the template in another dot-C file, into which our template declaration is #included:
// basics/myfirstmain.cpp
#include "myfirst.hpp"
// use of the template
int main()
{
double ice = 3.0;
print_typeof(ice); // call function template for type double
}
A C++ compiler will most likely accept this program without any problems, but the linker will probably report an error, implying that there is no definition of the function print_typeof().
The reason for this error is that the definition of the function template print_typeof() has not been instantiated. In order for a template to be instantiated, the compiler must know which definition should be instantiated and for what template arguments it should be instantiated. Unfortunately, in the previous example, these two pieces of information are in files that are compiled separately. Therefore, when our compiler sees the call to print_typeof() but has no definition in sight to instantiate this function for double, it just assumes that such a definition is provided elsewhere and creates a reference (for the linker to resolve) to that definition. On the other hand, when the compiler processes the file myfirst.cpp, it has no indication at that point that it must instantiate the template definition it contains for specific arguments.
The common solution to the previous problem is to use the same approach that we would take with macros or with inline functions: We include the definitions of a template in the header file that declares that template. For our example, we can do this by adding
#include "myfirst.cpp"
at the end of myfirst.hpp or by including myfirst.cpp in every dot-C file that uses the template. A third way, of course, is to do away entirely with myfirst.cpp and rewrite myfirst.hpp so that it contains all template declarations and template definitions:
// basics/myfirst2.hpp
#ifndef MYFIRST_HPP
#define MYFIRST_HPP
#include <iostream>
#include <typeinfo>
// declaration of template
template <typename T>
void print_typeof (T const&);
// implementation/definition of template
template <typename T>
void print_typeof (T const& x)
{
std::cout << typeid(x).name() << std::endl;
}
#endif // MYFIRST_HPP
This way of organizing templates is called the inclusion model. With this in place, you should find that our program now correctly compiles, links, and executes.
There are a few observations we can make at this point. The most notable is that this approach has considerably increased the cost of including the header file myfirst.hpp. In this example, the cost is not the result of the size of the template definition itself, but the result of the fact that we must also include the headers used by the definition of our template—in this case <iostream> and <typeinfo>. You may find that this amounts to tens of thousands of lines of code because headers like <iostream> contain similar template definitions.
This is a real problem in practice because it considerably increases the time needed by the compiler to compile significant programs. We will therefore examine some possible ways to approach this problem in upcoming sections. However, real-world programs quickly end up taking hours to compile and link (we have been involved in situations in which it literally took days to build a program completely from its source code).
Despite this build-time issue, we do recommend following this inclusion model to organize your templates when possible. We examine two alternatives, but in our opinion their engineering deficiencies are more serious than the build-time issue discussed here. They may have other advantages not directly related to the engineering aspects of software development, however.
Another (more subtle) observation about the inclusion approach is that noninline function templates are distinct from inline functions and macros in an important way: They are not expanded at the call site. Instead, when they are instantiated, they create a new copy of a function. Because this is an automatic process, a compiler could end up creating two copies in two different files, and some linkers could issue errors when they find two distinct definitions for the same function. In theory, this should not be a concern of ours: It is a problem for the C++ compilation system to accommodate. In practice, things work well most of the time, and we don't need to deal with this issue at all. For large projects that create their own library of code, however, problems occasionally show up. A discussion of instantiation schemes in Chapter 10 and a close study of the documentation that came with the C++ translation system (compiler) should help address these problems.
Finally, we need to point out that what applies to the ordinary function template in our example also applies to member functions and static data members of class templates, as well as to member function templates.
Here is a very good article about this topic.
The basics concern whether you should return 0 as success or 1 as success. In a main function , normally, you will return 0 as success and other variables as failure codes. However, when you try to map to boolean code, 0 is false, and non-0 is success, and that’s the extra level of confusion. So, if you do want to return boolean state as the function return value, it’s best to use bool, NOT integer.
This is copied from the helper file:
To ignore all CVS folders you should either specify a pattern of *CVS or better, the pair CVS */CVS. The first option works, but would also exclude something called ThisIsNotCVS. Using */CVS alone will not work on an immediate child CVS folder, and CVS alone will not work on sub-folders.
I understand that unit testing should cover most of scenarios if an application is nicely designed with some pro-unit testing framework, namely MVC pattern. In .Net world, those unit testing friendly frameworks include Asp.Net MVC, and Castle Project. But a lot of times, an application has already been designed and put into the production, you don't have time, money, and energy to re-write those anti-unit testing applications based on unit-testing friendly framework. Mostly importantly, business users don't understand why you want to rewrite an application just because you want to be able to unit testing it, they just need a workable application, and don't care too much about the back end unit testing which is an essential part of the whole project.
I am working on an application which is heavily depend on CSLA.Net framework, which is a very impressive framework. However, the framework is not very TDD friendly, and check out some discussions in this post. I started to look for some other alternatives which can automate the testing process, and the visual studio team system had an edition for software testers starting from Visual studio 2005. But honestly, I won't recommend using it unless you have the VS2008 version. The biggest limitation of VS2005 test version is that it doesn't support Ajax testing natively, and you have to rely on fiddler tool to record the testing. VS 2005 test version cannot detect dynamic parameter very well, and I have big trouble to get those viewstate related variables work. VS 2008 version definitely did a lot of improvements in those areas, although it's not free of bugs either. Check out an excellent post on web test in visual studio 2008 here.
A couple of roadblocks I have in working on the automating tests are:
1. You have to turn page validation off and view state check off. You probably want to turn it back in production environment.
2. You may need to hard code a machine key if you want to port the test to different sites. In our cases, we recorded the tests on a test website, but we also want to run it on stage site too.
1: <machineKey2: validationKey="9A1F64F585E06F97562808D96860AC9E3DA5F231EA34B42E8C98AE02B52EAF33CF7EF24C618F7F391756974090458C9740BE1007E6F898161C39B863A7E46C3D"
3: decryptionKey="376909E1031E5AA520AAE33B554ACACCE0CAEA2BA0B142FB3050D814059398CB"
4: validation="SHA1" decryption="AES"/>
3. Some post parameters are promoted as dynamic parameters incorrectly, watch out those if you need manually correct those.
4. Check out this web test plug in if you want to use some .Net functions in your test.
Sometimes, you want to create set up some specific pre-testing condition, and tear down those values added to your database in your testing, you can create a plug in to do this work.
In our projects, in PreWebTest, we create an object in the database which we need run our test on, and in PostWebTest, we delete this object. It works very well for our situation. We run those tests every day , and those green pass icons definitely make our life much easier.
I spent quite some time to figure this out, the process is not as easy or straightfard as the process to set up II6 on windows xp.
At firstly, I just go ahead and turn on the Internet Information Services and think that's all I need do.
But when I tried to open up the page, I got this error.
The trick is that under the "Internet Information Services", there are a lot of other settings you need check.
You have to enable those settings as well.
In the book "Advanced windows debugging", a detailed process on how to set up source server for the visual sourcesafe building. But most people today are now using the Team system to mange the code and build system, and here is an excellent link about "Setting up the Source Server for TFS builds".
Good stuff.
We have a couple of contractors who worked on our project before left. When they left, they didn't check in all the codes on their machine. I work on deleting some of the projects which have files checked out by them and are not used by anybody else now. I cannot do that because the TFS complains that some files were checked out by those contractors.
I googled around and found a simple solution in MSDN, the easiest way is to delete the workspace altogether:
Here is the exact command: tf worksapce /delete /server:servername workspacename[;workspaceowner].
The workspacename is normally the machine name.
Here is a post about how to enable sql cache dependency in sql 2005 http://davidhayden.com/blog/dave/archive/2006/04/29/2929.aspx
In visual studio, when you edit the CSS files, you can see the different sections which are supported by CSS. I have a couple of confusions regarding the difference between them.
<div id="tablist" >
<ul><li><a href="AgencyList.aspx">Agency List</a></li></ul>
<ul><li id="current"><a href="#">Agency Details</a></li></ul>
</div>
You define tablist as the Element Ids, but you can further define tablist ul, tablist li as the Elements, which are kind of one level below and essentially html elements. Similarly, you can define class firstly, and then define Elements. Element apply to the intrinsic html element such as body, h1, h2, p.
Element Id ends with “#” sign, Classes end with “.” sign, and Element ends with “nothing” :-)
I encountered a strange problem when working with a GridView control inside an Asp.Net ajax update panel. Basically, I have a portion of code look like this
1: <asp:UpdatePanel ID="UpdatePanel1"
2: UpdateMode="Conditional"
3: runat="server">
4: <ContentTemplate>
5: 6: <asp:GridView id="dgIFSPServices" runat="server" PageSize="15" AllowPaging="True" AllowSorting="True"
7: AutoGenerateColumns="False" Font-Size="9pt" Font-Names="Arial" width="100%" IsSortedAscending="True" BorderWidth="1px" BorderStyle="Solid"
8: ForeColor="Black" DataKeyNames="IFSPServiceID" DefaultSort="StartDate" RecordCount="0" OnRowEditing="dgIFSPServices_RowEditing">
9: <Columns>
10: <asp:CommandField ButtonType="Image" EditImageUrl="../../../Images/Edit.gif" ShowCancelButton="False" ShowEditButton="True"></asp:CommandField>
11: </asp:GridView>
12: 13: </ContentTemplate>
14: </asp:UpdatePanel>
And in the code behind page,
1: protected void Page_Load(object sender, EventArgs e)
2: {3: if (!IsPostBack)
4: {5: //Only binding data when the page is loaded at the first time.
6: }7: else
8: { 9: } 10: }
Every time, when I click the edit button in the <asp:CommandField> , the Page_Load is called twice. At the first time, IsPostBack is true, and the second time, IsPostBack is false. Since I have some special code which I definitely only want to run it when the page first loads, this double loading behavior causes some unpleasant effects.
After some extensive search, I found the answer in this post. It was decided how the command field is interpreted by the asp.net and rendered in the html page. In my example, it was rendered as
1: <INPUT style="BORDER-TOP-WIDTH: 0px; BORDER-LEFT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px;
2: BORDER-RIGHT-WIDTH: 0px" onclick="javascript:__doPostBack('ctl00$ContentPlaceHolderBody$IFSPReviewOld$dgIFSPServices','Edit$0')"
3: type="image" alt="Edit"
4: src="http://localhost:29162/Odh.EarlyTrack.UI/Images/Edit.gif" value="" />
The input type="image" is treated as a submit button by the browser, and will load the page once with IsPostBack=false, and onclick will load the page once again with the IsPostBack=true.
There is another alternative workaround in the post, you can subclass the linkbutton class, and use the linkbutton inside a template field to achieve the same purpose without the double post.
I have been helping our testers automate the test for our web applications, and right now, we are using VSTS testing and fiddler. Based on some information gathered from a post by James Avery, it seems I need check out some other options there, like WaitN, WaitN test recorder, also selenium, I guess my to do list will get much longer now.
And the biggest headache for our application is the lacking of automating testing, and since the application was developed by some other contractors originally, I am very cautions to change any code since there is no automatic verification.
I have been working on a project called "EarlyTrack" for the state of Ohio in the last 8 months, and the best thing I found is the "AVICode" monitoring tool installed on the production machine.
As a developer for the last 6 years, I understand that every application will have bugs in production no matter how much you test on your test environment. But when the user complains that they have ran into an issue, it is very hard to find what exactly goes wrong because of the challenge of recreating the exactly same issue. AVICode provides the exactly solutions for this kind of issue, it intercepts the exceptions thrown by the system and records very detailed information on what exactly happened in the cod when the bugs were triggered.
The most impressive thing is that if you installed the pdb(debugging database) file alongside the released binary file, every time a bug triggers, you can double click to get to the exact line of code which failed.
I'll take some screen shots later on..
There is a good article about C String, basically, there are two ways of declaring a string, either statically or dynamically.
1: char label1[]="I am a test!";
2: char label2[100]="I am a test!";
The length of the first string is decided by the actual string length, while the second string is explicitly declared as having the length of 100. Both of ways declare a mutable string, which is different with char* label3="I am a test!". The later one are essentially the same with const char* label3="I am a test!" . If you try to do something like lable3[0]='i', you will encounter an access violation error.
Here is a good link about this problem: Basically, when you declare char* label3="I am a test!". it will be a constant string in the data section, this string constant has always the same address and is constant. You should always consider const char* label3="I am a test!" because the former is only for backward purpose.
2. To declare a string dynamically, the string length has to be passed in like this char* dynamicalString=new string[length+1]. The last character is reserved for '\0', the end of string. The string length (strlen) is length, not length+1.
A very good post on how to change the configuration of the enterprise library.
I think I am not very clear about those different loading functions, so I looked up a couple of different sources, and it helps a lot. Here are some understanding I summarized:
References:
My experience tells me that if your web applications (or even the windows applications) run slower, 90 percent of the time, it's because some sql queries, stored procedures, indexes on the tables are not optimized. It's very important that you can find which query, which table are running slowly.
The book "SQL Server Query Performance Tuning Distilled" by Sajal Dam is a very good book on this topic.
Here is a simple example of parameter passing in C#..
1: public class ParameterPassingSample
2: {3: public ParameterPassingSample()
4: { 5: } 6: 7: public void CallingMethod()
8: {9: StringBuilder sb1 = new StringBuilder("Test");
10: CalledMethod(sb1);11: System.Diagnostics.Debug.Assert("Test test"==sb1.ToString(),"String equal");
12: } 13: 14: public void CalledMethod(StringBuilder sb2)
15: {16: sb2.Append(" test");
17: } 18: }Since CalledMethod function changed the sb value, it will easily give you an impression that Parameter is passed by reference. Actually, it's not.
Sb2 is a new string builder object, and it points to the same string builder object in memory. So, when CalledMethod change the value, the value which the original string object (sb1) refers also change. This doesn't mean "pass by reference", it is still "pass by value". Here is another example to show this.
1: public class ParameterPassingSample
2: {3: public ParameterPassingSample()
4: { 5: } 6: 7: public void CallingMethod()
8: {9: StringBuilder sb1 = new StringBuilder("Test");
10: CalledMethod(sb1);11: System.Diagnostics.Debug.Assert("Test"==sb1.ToString(),"String equal");
12: } 13: 14: public void CalledMethod(StringBuilder sb2)
15: {16: sb2 = null;
17: } 18: }Here , if sb2 changes to null, it doesn't affect the value of sb1.
The difference between those two examples are "change the value the parameter points to" or "change the value of the parameter itself".