- Configuring Continuous Integration (CI) with VSTS Build services
- Adding unit testing and validation to the CI process
- Adding Continuous Deployment (CD) with VSTS Release Management & Azure PaaS
- Adding automated performance testing to the pipeline
- Promotion of the deployment to production once validated
- Sending feedback on completion of the process to Slack
In my case, I didn’t want those temporary files to show up at all – not even in the Excluded Changes list. In order to gain control over which files TFS should ignore completely, I added .tfignore files to my solution. These allow you to specify which files, extensions and directories to ignore (or un-ignore!) from source control. If you’re familiar with the concept of .gitignore files in GIT, you should feel right at home.
- Xamarin platform
- PhoneGap framework
- Native Android development via Java
The Xamarin platform provides the ability for .NET developers to harness their C# knowledge, create cross-platform (iOS, Android and Windows) applications, reuse existing code and perform development within Visual Studio. The greatest advantage of utilizing the Xamarin platform is a reduced time to market while supporting multiple platforms. However, due to the additional Xamarin runtime contained within the final application, the footprint tends to be larger — this could be an issue, especially for some Android devices.
While Xamarin and PhoneGap certainly have their merits for creating Android applications, native Android development via Java provides an opportunity to take advantage of a device’s full feature set with fast execution, all wrapped in a smaller package for more rapid downloads. For a complete discussion of the various mobile platforms’ benefits/drawbacks, please read Eric Svendsen’s excellent article where he provides plenty of depth on the issue. For now, the remaining content of this post will be to provide valuable insight for .NET developers looking to expand their language set by utilizing native Java for Android development. Read More…
|GET||/api/order||Returns all orders|
|GET||/api/order/3||Returns details order #3|
|POST||/api/order||Create new order|
|PUT||/api/order/3||Update order #3|
|DELETE||/api/order/3||Delete order #3|
The above is considered verb-based routing. The URLs above only contain the controller name and an optional id. So the Web API uses the HTTP verb of the request to determine the action method to execute in your ApiController subclass.
Now what if you want to add some custom actions to your ApiController subclass? For example:
|GET||api/order/3/vendors||Returns all vendors involved with providing items to complete order #3|
|PUT||/api/order/3/expedite||Expedites order #3, but can only be executed by managers in customer service dept.|
|PUT||/api/order/3/reject||Rejects order #3, but can only be executed by managers in customer service dept.|
It turns out that adding those custom actions is hard, very hard. But keep reading. There is an easy way. Read More…
Strangely, we started noticing that the names of the metrics (which were also being written to a SharePoint list) were displaying some incorrect results…names like “ShowAllItemsOpened” were instead “showAllMenuItem_Click.” What’s that you say? Clearly that’s the name of an event handler! Well, you’d be right! But it worked before! What changed in testing? First, some background information …
As noted in the previous post, the System.TimeZoneInfo uses AdjustmentRules to account for DST Transitions, and the default AdjustmentRules do not incorporate all the available DST data. But it is possible to create a custom TimeZoneInfo and populate the AdjustmentRules with DST Transition data available to cover all DST transitions.