If you are like me and keep missing the ASP.NET community standup, or scramble to clear your schedule when you see a tweet from Scott Hanselman minutes before they go live... well no worries it turns out that most (if not all) are available on the .NET Web Development and Tools Blog
and they are all tagged with CommunityStandup
There is a phenomenal amount of information and posts ... I know shocker !!!
The project I'm currently involved in, we are currently supporting one language (French) and we we're told this would not change in the near future ... Guess what the near future is now !!! An opportunity presented itself and our client wanted to grab it, so we we're tasked with making our app support english as well. The good news was that we we're already using .resx files ..... the bad news is that those files are everywhere!!!
Things got a little more interesting when the client told us he hired a guy to work on the entire translation instead of us having to do it ... great so now we have to take some guy that has no clue about what a resource file is and sit him down ...launch Visual Studio and make him add support for english!!! might as well do it ourselves !
Resxtranslator to the rescue
I took some time to try and find a tool that would allow the translator to do the work he was being paid for without me having to do a crash course on Visual Studio. After a few moments I found the little gem it's called Resxtranslator it's on Github
and it does exactly that... let the translator work !!!
After a few tests a was confident enough that the translator could use this tool and my team would not be impacted by him asking a bunch of questions if he we're in an IDE (which would be 100% understandable)
After a few moments of explanation, the translator went to work and in the matter of a day and half he was done! No files we're forgotten or missed, it was unbelievable. Every file was now translated and we we're now supporting both french and english (with french fallback in case). The only work left to do was to actually include every single file in its corresponding project, then we deployed it to a staging area and bingo it was done.
Definitely a tool to keep close as soon as the resource file is added we now go straight to this tool to add the support for both.
Don't forget to check it out !!
We've all done this at least once during development or for some demos we'll store some secret key in our web.config then commit by mistake in a public repo (even in private repo... not s bad but still bad). This has gotten so bad that if you commit what looks like an Azure secret key in a public repo, you will eventually receive (few minutes to few hours after commit) an email from Microsoft stating that your repo contains what looks like a secret key and you should think about disable it !!!!
Enter the SecretManager
When developing a new web project using ASP.NET core you now have at your fingertips a SecretManager that stores on your machine those secret value that must NOT be commited.
The beauty of the SecretManager is that you won't need to change anything in your development code vs deployment code.
Setting it up
If it's not already present in your project you will need to setup it up .... so here it goes:
- At the root of project.json add a key "userSecretsId" with a unique value (GUID) like so projectName-GUID
- in project.json add a dependency on "Microsoft.Extensions.Configuration.UserSecrets": "1.0.0"
- In project.json in the root node add "Microsoft.Extensions.SecretManager.Tools": "1.0.0-preview2-final" (current version as of 2016-10-06)
- run dotnet restore
Make sure that SecretManager is ready by running this command :
dotnet user-secrets -h
If you get an error message it's probably because you are in the wrong folder (like I did), this command must be run in the project folder otherwise you must specify the project full path by adding --project "project\full\path"
Using the SecretManager
In using the SecretManager we'll continue to access our secret key just like they we're in the web.config. So the line of code is still valid
var value = Configuration["Auth:Google:Id"];
Make sure that in Startup.cs you have this block of code:
Storing values in SecretManager
Alright so our SecretManager is setup, we can read from it (using the Configuration class as we are used to), but now how to we store values in the SecretManager
dotnet user-secrets set Auth:Google:Id ValueOfId
Dont't forget to run this command from the project folder or to specify to project full path by using --project
- Currently (2016-10-06) the values stored in the SecretManager are not encrypted
- You will still need to provide the production values for production (azure application settings or some other form)
Lots of new features are bundled in this release of Visual Studio 15 preview !!! My favorite is how fast it can open a BIG solution and how seamless it is to switch from one branch to another without the constant reloading...good stuff!
Improvements in performance:
- Shorter solution load time with lightweight project load (my favorite)
- Faster startup with on-demand loading of extensions
- Moving subsystems from the main VS process to separatel processes
- Faster project load, coding, and debugging for C++
- Improved speed of Git source control operations by using git.exe
Improvements in productivity:
- Code Edition
- Quick Fixes and Refactorings (close second)
- Code Navigation
Check out the fully detailed blog post, the release notes or go straight to the installer
So you have already configured your continuous deployment with Azure and now find yourself in need of making sure that webjobs get deployed at the same time. Because once you start using webjobs you just can't go back they are so powerful yet so simple, but how to deploy them all at the same?
It's really simple, if you do not yet have a console app in your solution, you just right click on you web project and choose Add -> New Azure Webjob Project, fill out the information (project name, how you want that job to execute, ...) then Visual Studio will get the ball rolling by creating a new console project and download a few dependencies from Nuget, and your good to go.
On the other hand if you already have a console app, it's as simple... once again right-click on you web project Add -> Existing Project as Azure Webjob.. then you'll just have to choose that console app... fill out the same info for the project and there you have it.
On every deployment for your project your webjobs will also get deployed