안녕하세요. 코난 김대우 입니다. 지난 10월 6일 WebMatrix Beta2가 공식 발표 되었습니다.
Beta2가 발표되고 제가 만들었던 강좌들의 코드가 일부 동작하지 않는 경우가 있으셨을 거에요. Beta1과 Beta2의 차이 때문입니다.

이렇게 Beta 기간에는 기능에 대한 변경이나 기능 추가가 빈번하게 있을 수 있지요. 보통 RC버전(Release Candidate)까지는 이렇게 변화가 종종 있다가, RC 이후부터는 안정화 단계만 진행해 정식버전 발표(RTM)이 된다고 보시면 됩니다. 이런 Beta 버전의 중요한 변경점을 “Breaking Change” 라고 보통 이야기 합니다. 

Beta2에 이런 Breaking Change가 여럿 존재하게 된 이유는 ASP.NET MVC의 Razor Syntax와 호환성을 맞추기 위해서가 가장 큰 이유였다고 합니다. 아울러, Helper들의 추가와 같은 기능 추가도 빼놓을 수 없겠지요.

Beta2의 Breaking Change는 어떤게 있었을까요? 마침 잘 작성된 문서가 있기에 간단히 섹션별로 소개 정도만 해보도록 할께요. 웹 개발 경험이 있으시고, 제 Razor 강좌를 쭈욱~ 따라와 보신 분들은 변경점 예제 코드만 보셔도 바로 감이 오실 거에요.
도움 되시길 바랍니다.

참조 :
http://learn.iis.net/page.aspx/949/webmatrix-beta-2-release-readme/ 


 

Change: ASP.NET Razor 구문의 주석(Comment) 관련 변경
The syntax for including comments has changed. The old syntax was this:
@// Your code comment here.

@/* 
    A multi-line 
    server-code comment  
*/

The new syntax is this:

@*  A one-line code comment. *@
	
@* 
    A multi-line comment. 
    server-code comment
*@

This change affects only comments that use the old Razor commenting syntax. Comments that use language-specific syntax (such as // or /* */ in C# or ' in Visual Basic) still work as is within code blocks.

 

Change: "Database.OpenFile"이 사라지고, "Database.Open" 으로 변경됨

In Beta 2, ASP.NET Web Pages supports two methods for opening database files or connections, as shown in the following examples:

Database.Open("SmallBakery");

Database.OpenConnectionString("server=myServer;database=myDatabase;providerName="System.Data.SqlClient");

The Database.OpenFile method has been removed.

The recommended method is Database.Open, because it makes it easy to migrate a SQL Server Compact database (.sdf file) to a full version of SQL Server. When you pass a name to Database.Open, the method first looks for a connection string of that name in the Web.config file. If no such connection string exists, the method adds ".sdf" and ".mdf" to the name and then looks in the App_Data folder for a database of that name. This lets you use a local .sdf file for development, but then at deployment time, create a connection string that has the same name and that points to the SQL Server instance on the hosting site.

For more information, see the tutorial Working with Data.

 

Change: 일부 Type과 Member 이름이 변경됨
Some types and members (including some helpers) have been renamed in order to avoid conflict with types in .NET Framework namespaces or to better reflect their semantics. The following table lists changes.

Old name
New name

Mail
WebMail

LayoutPage
Layout

Response.WriteJson
Response.Write(Json.Encode(<object>))

 

 

Change: "RenderSection"의 "Optional" 메서드 파라미터가 "Required" 로 변경되었습니다.

In the Beta 1 version of ASP.NET Web Pages, the RenderSection method used in layout pages supports an optional parameter that lets you specify that the content page does not have to provide content for that section:

@* Syntax for Beta 1 release *@
@RenderSection("scripts", optional: true);

In the Beta 1 release, if a layout page includes a RenderSection method that does not include the optional parameter, and if content is not provided for that section, an error occurs.

The semantics of this parameter have changed in the Beta 2 release. The parameter is now named required. To make a section optional, you set required to false, as in this example:

@* Syntax for Beta 2 release *@
@RenderSection("scripts", required: false);

The behavior continues to be that a section is required unless this parameter is set to make the section optional.

 

Change: application and page values 설정이 변경되었습니다.(전체 페이지 실행시 자동 수행 모듈과 폴더내 파일 실행시 자동 수행 모듈)

In the Beta 1 release, you can set application-wide (that is, global) values using the AppData dictionary in the _start.cshtml file. Similarly, in Beta 1, you can set page values in the _init.cshtml file using the PageData dictionary.

The Beta 2 release features two changes to these settings:

  • The files have been renamed:
    • _start.cshtml is now _AppStart.cshtml
    • _init.cshtml is now _PageStart.cshtml
  • The AppData dictionary has been renamed to AppState.
  • Dynamic App and Page properties are now available that provide an alternative way to using the dictionary to set and get the values. These properties provides access to the same data that the dictionaries do, but provide a convenient way to use the values.

The following example shows how to use the App property.

@* _AppStart.cshtml *@
@{
    // Using dictionary
    AppState["SiteName"] = "My Site";

    // Using dynamic property
    App.SiteName = "My Site";
}
<!DOCTYPE html>
<html>
<body>
  <p>Site name: @AppState["SiteName"]</p>
  <p>Welcome to @App.SiteName</p>
</body>
</html>

The following examples shows how to set the Page property in the _PageStart.cshtml file, and then to reset it in the code for an individual page. You can set these values anywhere that's specific to the current request (in effect, anywhere except in the _AppStart.cshtml file).

@* _PageStart.cshtml *@
@{
    Page.Title = "My Site";
}
@* Default.cshtml *@
@{
  Layout = "_Layout.cshtml";
  Page.Title = "My Page " + Page.Title;
}
<div>Some text</div>

@* _Layout.cshtml *@
<html>
    <head>
        <!-- Renders "My Page - My Site" -->
        <title>@Page.Title</title>
    </head>
    <body>@RenderBody()</body>
</html>

For more information about using these files, see the tutorial Customizing Site-Wide Behavior.

Note for Visual Basic users   Due to restrictions in how Visual Basic works, you cannot use the dynamic App and Page properties unless the application is running in full trust (that is, if it is running in medium trust). However, you can use the AppData and PageData dictionaries no matter what trust level the application is running at. It is anticipated that this will be fixed in a future version of the .NET Framework.
Note also that if you are using Visual Basic, the filename extensions are .vbhtml for example, _AppStart.vbhtml.

 

Change: URL 라우팅시 URL 파싱의 순서가 변경 되었습니다.

In the Beta 1 release, URLs are parsed left to right. As soon as ASP.NET finds a page that matches a segment of the URL, the page is invoked and the remaining segments of the URL are passed to the page as data. As a result, in Beta 1, ASP.NET is not able to find pages that matched more specific segments of the URL if a more general page existed. For example, imagine this URL

http://mysite/subpage1/page1

And imagine that you have this structure in the website:

\subpage1.cshtml
\subpage1\page1.cshtml

In the Beta 1 release, the URL would resolve to subpage1.cshtml and pass "page1" as data to the page.

In Beta 2, the parsing has been reversed so that ASP.NET finds the more specific page first. In the example, ASP.NET would find page1.cshtml when the example URL is used.

For more information about how URLs are parsed, see "Creating More Readable and Searchable URLs" in the tutorial Customizing Site-Wide Behavior.





profile

부족하지만, SQLER의 누군가와 함께한 나눔을 통해 제가 더 많이 즐거웠습니다.
SQLER와 함께 즐거워 할수록, 그 나눔을 통해 더 많은 기회와 가치를 발견하게 되었습니다.
나눔의 생각이 앞으로도 계속, SQLER를 움직일 것입니다.

코난, 김대우 / SQLER 운영자 / 골라먹는 SQLER RSS 정보 구독 / 실시간 SQLER 소식 uxkorea 트위터