Visual Studio 25th Anniversary!! I have used Visual Studio for 25 years!!

Time flies!

It is Visual Studio 25th Anniversary. It also means that I have worked on Visual Studio for 25 years too. (Oh no, getting old so fast…… from a young kid to an old man…)

[1997] I learn NT3.51 and VB during my last year on my bachelor degree study. I graduated from my bachelor degree. I still remember that I learn VB5 with VS1997 in my first job in a software company which is a Microsoft Certified Partner.

 

[1999] Then I start using VS 6.0 for VB6, Traditional ASP, and also using Visual SourceSafe.

 

[2000] Then I start building .NET application from VS.NET beta. At the same time, I heard from Microsoft .NET team saying that .NET will be last for at least 10 years, from 2000 to 2010. It will be the first language to do all the Web Development and Win Development in same preferred programming language.  Microsoft introduce C# at the same time. I choose staying in VB.NET as I have VB background. Start developing some Web Services.

[2001-2003] I made friends with other local .NET developers and also local Microsoft MSDN team. We then formed a local community HK .NET User Group. At the same time, I participle a lot on Microsoft Forum HK and TW. I was then awarded to be Microsoft Community Star TW, then Microsoft Community Star HK, and then Microsoft MVP @TW on VB technology.

 

[2005] .NET Framework 2.0 released with VS2005. As being VB MVP and attended 3 times Global MVP Summit. We VB MVPs always complained that the sample code are in C# more than VB.NET in MSDN library. in the end of 2005, I started moving into C#. I could do VB.NET and C# at the same time.

 

[2006] I helped VB team to translate the hands on lab from C# into VB.NET.
Windows Workflow Foundation and Visual Basic .NET
My previous blog links:
Windows Workflow Foundation(WF) Hands-On Lab01 to Lab03 in VB2005
Finished the Translation on WF HOL Lab04 to VB2005

 

[2008] Microsoft introduced Entity Framework. We called it Database-First EDM.

 

[2010] With VS2010, I start learning and developing ASP.NET MVC. Microsoft released Silverlight, a web version of WPF. (at least I think so)

 

[2012] EF 4 released, now it supported Code-First EDM.

 

[2015] EF 6, Owin, OAuth, WebAPI…

 

[2017] MVC5, Dependency Injection, .Net Core…

 

[2019] .NET Core 3

 

[2022] .NET core and .NET Framework now becomes .NET, starting from .NET 5. With this version, the experience on windows app development is not good as in VS2019. Specially right after I stopped the debugger.

 

Now, you could also download this special VS 25th Anniversary Theme Pack. Don’t wait, get it and try it.

 

 

 

 

 

 

Global AI Bootcamp 2022 @Hong Kong

I am helping to speak in Global AI Bootcamp 2022 (Hong Kong) on 14 January 2022. This event’s objective is to give younger generations more ideas and passion for AI. Speakers of this event include Eason Lai (Global Technology Strategist @ Microsoft; Microsoft AI MVP), Ricky Shiu (Data Scientist @ AIA Hong Kong and Macau), and Ken Lin (Senior Technical Consultant (APAC) @ Willis Towers Watson; Microsoft Dev rMVP). Please feel free to register and circulate.

https://globalai.community/bootcamp-2022/asia-hong-kong-ai-community-4838/

Enable TLS 1.2 or above on your ASP.NET Web App or WebAPI

The Transport Layer Security (TLS) 1.2 is a stadnard that provides security improvements over previous versions. More and more thrid-party APIs were configured to disable any requests from clients that were using TLS 1.0/1.1. So if your ASP.NET Web App or WebAPI Services Web Site will need to update to TLS 1.2 as well if your ASP.NET Web App or WebAPI Services Web Site has some calls to the third-party APIs, otherwise they will only return empty responses.

You could disable TLS 1.0/1.1 and only enable TLS 1.2 in your Web Server or in Azure, so that your hosting environments will no longer accept requests from earlier version of TLS.

But what happens on your application (ASP.NET Web App or WebAPI Services)? Depend on what version of .NET framework your project usrs will dicate the possible solutions available to you.

  1. If your project compiles against .NET Framework 4.7 or above, then you don’t have to do anything.
  2. If your project has been developed in a earlier version of .NET Framework, then you could either
    1. Recompile your project using .NET Framework 4.7 or above
    2. If recompiling is not an option, then you will have to update your .config file as below,
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
  </runtime>
  <system.web>
    <compilation targetFramework="x.y.z" />
    <httpRuntime targetFramework="x.y.z" /> 
  </system.web>
</configuration>

It is preferred that x.y.z are the same. So if your application is 4.6.2, then replacing x.y.z into 4.6.2.

Microsoft also has post a useful document on describing the best pratices to TLS 1.2. It will be great if you could read them all and understand them in order to fully secure your application(ASP.NET Web App or WebAPI Services).
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

 

“Package is not found…” when updating NuGet Package from Azure DevOps

if you are using the Azure DevOps, you may already know that it provides Azure Artifacts (it was called NuGet Package Management before VSTS renamed to Azure DevOps). With that you could create and share NuGet pacakges feed from public and private sources.

With the Azure DevOps CI pipeline, you could then build your solution, pack and push the NuGet package into private Azure Artifacts.

If you are already running in this way, you may have experience on trying to update the existing NuGet Package and it returns an error,

“Attempting to gather dependency information for package ‘xxx.newer.version’ with respect to project ‘ThisProject’, targeting ‘.NETFramework,Version=v4.7’

Package ‘xxx.newer.version’ is not found in the following primary source(s): ‘https://[YourDevOps_Name].pkgs.visualstudio.com/_packaging/[Your_AzureArtifacts_Name]/nuget/v3/index.json,https://api.nuget.org/v3/index.json’. Please verify all your online package sources are available (OR) package id, version are specified correctly.”

I tried to search from internet and found someone who is working in Microsoft has replied on 10th May 2018 as the following,


“Seems you are trying to download the package or packages that where just freshly pushed to VSTS nuget feed.
Since Visual Studio 2017 is listing it correctly, then the issue should not related to the feed on VSTS server.
If this occurs very recently(download the new refresh package) and your package is very large, this maybe a network delay. Suggest you use a fiddler trace when this issue happens again. This makes “some” sense, what you see is probably an incorrect propagation of pushed packages showing up in the search results but not yet available to download.
And some other also encounter the same issue and error as you.”

Well, I tried to use fiddler to see what is happening when I tried to update the package. Because I have also set up the upstream sources, so it checks on all the available NuGet Packages in private Azure Artifact until it founds the match one. (That also explains me another question, why it takes so long to attempt the dependency information for the updating NuGet Package). I could confirm that the newer package is updated in feed and may be taking a longer time to upload the actual package.

So next time, if you found the similar message when updating NuGet Package from Azure Artifact, you could do,

  1. Wait and retry later.
  2. if the problem keep exists, you could try to clear the NuGet Cache from VS–>Tools–>Nuget Package Manager–>Package manager Settings–>General.

Supporting HTTP method ‘OPTIONS’ and CORS for Web API

Enable CORS

If you read the Web API tutorials from docs.microsoft.com, all of them are teaching you to create the server app (Web API) and the client app (ASp.NET MVC) in the same solution. In fact, we usually separate the server and client application into separate applications. You will then find out the client application cannot call any Web API method in server application. It is because of the CORS.

Cross Origin Resource Sharing (CORS) is a W3C standard that allows a server to relax the same-origin policy. Using CORS, a server can explicitly allow some cross-origin requests while rejecting others. CORS is safer and more flexible than earlier techniques such as JSONP. This tutorial shows how to enable CORS in your Web API application.

If you application is ASP.NET Web API 2, now you could do the following to enable CORS

  1. install Microsoft.AspNet.WebApi.Cors from Nuget

  2. Open file App_Start/WebApiConfig.cs. In Register method, add this code config.EnableCors();

  3. You can then adding “[EnableCors(origins: “https://localhost:8080”, headers: “*”, methods: “*”)]” to any method that you want to enable CORS

  4. You could also add the following into Web.config, so that CORS will be enabled to all methods

    <httpProtocol>
    <customHeaders>
    <!-- Allow Web API to be called from a different domain. -->
    <add name="Access-Control-Allow-Origin" value="*" />
    <add name="Access-Control-Allow-Methods" value="*" />
    </customHeaders>
    </httpProtocol>

Now your server application Web API is ready to serve other client applications’ calling. You could read more here, Enabling Cross-Origin Requests in ASP.NET Web API 2

Support HTTP Method ‘OPTIONS’

If your client code is calling the Web API in javaScript, the execution will be fine on Http GET and POST. If your javaScript is Http PUT or DELETE, you will find this error,

The requested resource does not support http method ‘OPTIONS’.

 

Most of the browser will send a Preflight Request before it sends the actual request. One of the conditions to skip the Preflight Request is “The request method is GET, HEAD, or POST”. if you search to solve it, you will find that most of the result are stating that you could add and remove some handler in web.config could help.

Someone reported that it really solve the problem, but it does not work in my environment. I then also found out that there is another work around and it really works for me. (This is also the main reason why I blog it down and share with you now.) We now adding some handling to the HTTP OPTIONS verb in BeginRequest method.

protected void Application_BeginRequest(object sender, EventArgs e)
{
if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
//These headers are handling the "pre-flight" OPTIONS call sent by the browser
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
HttpContext.Current.Response.AddHeader("Access-Control-Allow‌​-Credentials", "true");
HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000");
HttpContext.Current.Response.End();
}
}

 

BINGO!

If you check in Fiddler, now the Server Application Web API is accepting the OPTIONS method and response to your client app that the is now ready to receive your PUT/DELETE call.