Another #BrandonEpisode of the #msdevshow where we talk about the announcements from Microsoft’s latest //build/ conference:
Also, congrats on 100 episodes to the MS Dev Show team; glad I could be a part of a big mileestone!
A problem that my team has been running into on-and-off since working with ASP.NET Core is having a local install of our node toolchain fighting with Visual Studio’s built-in version of node. Luckily, my coworker discovered the source of the issue (thanks, Pete!). Continue reading…
Another #BrandonEpisode of the #msdevshow where we talk about working remotely and telecommuting in general:
If you haven’t been paying attention to the “New Microsoft”, you may have missed that a lot of their new code is ending up on places like Github. Included in that is the backbone of their new Visual Studio Team Services build and deploy services: tasks.
In exploring the Github repository, I noticed that they were making use of some interesting, non-public modules (primarily in the
Microsoft.TeamFoundation.DistributedTask.* namespace). Several of their scripts referenced code like this:
# Import the Task.Common and Task.Internal dll that has all the cmdlets we need for Build Import-Module "Microsoft.TeamFoundation.DistributedTask.Task.Internal" Import-Module "Microsoft.TeamFoundation.DistributedTask.Task.Common"
In attempting to create my own tasks, I found that I couldn’t do that same import. Errors like this would prevent me from utilizing them:
##[error]import-module : Could not load file or assembly 'Microsoft.TeamFoundation.DistributedTask.Agent.Interfaces,
Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
+ import-module "Microsoft.TeamFoundation.DistributedTask.Task.Internal"
+ CategoryInfo : NotSpecified: (:) [Import-Module], FileNotFoundException
+ FullyQualifiedErrorId : System.IO.FileNotFoundException,
After much investigation, I found where the modules live on the VSO/VSTS server. Change your import line to directly reference the agent’s module path:
# Import the Task.Common and Task.Internal dll that has all the cmdlets we need for Build $agentWorkerModulesPath = "$($env:AGENT_HOMEDIRECTORY)\agent\worker\Modules" $agentDistributedTaskInternalModulePath = "$agentWorkerModulesPath\Microsoft.TeamFoundation.DistributedTask.Task.Internal\Microsoft.TeamFoundation.DistributedTask.Task.Internal.dll" $agentDistributedTaskCommonModulePath = "$agentWorkerModulesPath\Microsoft.TeamFoundation.DistributedTask.Task.Common\Microsoft.TeamFoundation.DistributedTask.Task.Common.dll" Write-Host "Importing VSTS Module $agentDistributedTaskInternalModulePath" Import-Module $agentDistributedTaskInternalModulePath Write-Host "Importing VSTS Module $agentDistributedTaskCommonModulePath" Import-Module $agentDistributedTaskCommonModulePath
The vital part is the
$env:AGENT_HOMEDIRECTORY. This is a predefined variable available to the build runner pointing to the agent’s home directory. Underneath this is where the tasks, modules, and other agent-specific assets live. After prefixing the modules with the proper path, I was back in business!
Hopefully this helps someone; I couldn’t find a single piece of info on this. Good luck!
I finally had a chance to get our codebase to the release candidate of ASP.NET 5. Excited to have a supported release available and more-or-less production-ready! As usual, here are my personal release notes to my team on the upgrade process.
Good Afternoon, Everyone:
The upgrade to release candidate 1 (update 1) has been completed. As with previous beta updates, Visual Studio requires updated tooling; this time it’s in the form of Visual Studio 2015 Update 1 (download) (release notes).
And don’t forget to update your dnvm stuff from the command line:
You may want to remove all other betas from your user folder:
The following announcements/issues were relevant to our codebase to some degree:
- Moving towards unification of entry point semantics with desktop CLR
- Switching to new ‘dotnet’ target framework monikers
- webroot definition moved from project.json to hosting.json
- ConfigurationBuilder SetBasePath is now optional
- EntityFramework.SqlServer package renamed to EntityFramework.MicrosoftSqlServer
- Authentication: AutomaticAuthentication has been split
- Microsoft.Framework.* has been renamed to Microsoft.Extensions.*
And just a couple to take note of:
- SecretManager package has been renamed to Microsoft.Extensions.SecretManager
- New versioning for major releases
- Templates repo is now public
- Changes to `dnvm` parameters
Some additional references:
I join the awesome hosts of the MS Dev Show to discuss some of the announcements from Microsoft’s Connect() 2015 conference. We touch on ASP.NET 5, Visual Studio Team Services, and Visual Studio Code. Check out the podcast here:
I don’t know why it took me so long to figure this out, but it’s totally possible to deploy binaries from the DNU toolchain instead of source folders. Continue reading…
After deploying one of our ASP.NET DNX web applications to Azure, we were running into this exception:
The specified CGI application encountered an error and the server terminated the process. Continue reading…