Some additional searching on changes to code access security revealed a very helpful article on migrating partially-trusted assemblies. What I posted yesterday about preserving the previous behavior is found a little over halfway through the article, in the Level1 and Level2 section.
One thing this new article makes clear is that use of SecurityRuleset.Level1 should only be used as a temporary measure until code can be updated to support the new security model.
Code access security is one area that has changed quite significantly between .NET 3.5 and .NET 4.0. Once an assembly has been upgraded, if it allowed partially-trusted callers under .NET 3.5, it would throw exceptions when called under .NET 4.0. In order to make such assemblies continue to function after being upgraded, AssemblyInfo.cs needs to change from this:
[assembly: AllowPartiallyTrustedCallers]
to this:
[assembly: AllowPartiallyTrustedCallers]
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Once this change has been made, the assembly will work under the same code access security rules that applied prior to .NET 4.0.
Planet Money, one of many podcasts I listen to in Beltway traffic, had a great episode recently attempting to explain why GDP is important. The reporter contrasts the resources for a school in Kingston, Jamaica with a socioeconomically similar school in Barbados. The difference in what a country can do with a per-capita GDP of approximately $15,000/year (Barbados) versus around $5600/year (Jamaica) turns out to be quite staggering. Hearing about teachers paying for school materials out of their own pockets sounded a lot like what I’ve heard and read in news stories and features about inner-city schools here in the U.S. One part of the piece that I believe has broader applications to how foreign direct investment (FDI) is used worldwide is when Jamaica’s minister of education (Andrew Holness) explained why the FDI Jamaica has received hasn’t resulted in the expected benefits to the country. It boiled down to not having enough sufficiently-educated people to staff the projects being built, whether it was bauxite plants or anything else.
A paper by Peter Blair Henry (a Jamaican-born economist) goes into more detail on the comparison between Barbados and Jamaica. There’s also a podcast of him from last year on the same subject. I can’t vouch for these latter two links (yet), but the Planet Money episode is worth a listen if you’re at all interested in economics.
Lately, I’ve been making significant use of the ExecuteDDL task from the MSBuild Community Tasks project in one of my MSBuild scripts at work. Today, someone on the development team got the following error when they ran the script:
“Could not load file or assembly ‘Microsoft.SqlServer.ConnectionInfo, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91’
It turned out that the ExecuteDDL task has a dependency on a specific version of Microsoft.SqlServer.ConnectionInfo deployed by the installation of SQL Server 2005 Management Tools. Without those tools on your machine, and without an automatic redirect in .NET to the latest version of the assembly, the error above results. The fix for it is to add the following XML to the “assemblyBinding” tag in MSBuild.exe.config (in whichever .NET Framework version you’re using):
<dependentAssembly>
<assemblyIdentity name=”Microsoft.SqlServer.ConnectionInfo” publicKeyToken=”89845dcd8080cc91″ culture=”neutral” />
<bindingRedirect oldVersion=”0.0.0.0-9.9.9.9″ newVersion=”10.0.0.0″ />
</dependentAssembly>
Thanks to Justin Burtch for finding and fixing this bug. I hope the MSBuild task gets updated to handle this somehow.
I came across this blog post in Google Reader and thought I’d share it. The idea of being able to outsource the care and feeding of a continuous integration system to someone else is a very interesting one. Having implemented and maintained such systems (which I’ve blogged about in the past), I know it can be a lot of work (though using a product like TeamCity lightens the load considerably compared with CruiseControl.NET). Stelligent isn’t the first company to come up the idea of CI in the cloud, but they may be the first using all free/open source tools to implement it.
I’ve read Paul Duvall’s book on continuous integration and highly recommend it to anyone who works with CI systems on a regular basis. If anyone can make a service like this successful, Mr. Duvall can.
When you first get started with PowerShell, don’t forget to run ‘Set-ExecutionPolicy RemoteSigned’ from the PowerShell prompt. If you try to run a script without doing that first, expect to see a message like the following:
File <path to file> cannot be loaded because execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.
The default execution policy for PowerShell is “Restricted” (commands only, not scripts). The other execution policy options (in decreasing order of strictness) are:
When I first tripped over this, the resource that helped most was a TechNet article. Later, I found a blog post that was more specific about the execution policies.
I’d been trying to launch the Cassini web server from a PowerShell script for quite awhile, but kept getting an error when I tried to display the configured website in a browser. When I opened up a debugger, it revealed a FileNotFoundException with the following details:
“Could not load file or assembly ‘WebDev.WebHost, Version=8.0.0.0, Culture=neutral, PublicKeyToken=…’ or one of its dependencies…”
Since the WebDev.WebHost.dll was present in the correct .NET Framework directory, the FileNotFoundException was especially puzzling. Fortunately, one of my colleagues figured out what the issue was. WebDev.WebHost.dll wasn’t in the GAC. Once the file was added to the GAC, I was able to launch Cassini and display the website with no problems.
Recruiters use Google. Whether you’re actively seeking a new job or not, it’s important to use this fact to your advantage. My friend Sandro gave me this advice years ago, when he told me to put my resume online and make it “googleable”. For me, the result was contacts from recruiters and companies I might never have heard of otherwise. In addition to putting your resume online, I would recommend blogging about your job–within reason. Definitely do not write about company secrets or co-workers. Putting such things in your blog doesn’t help you. Instead, write about what you do, problems you’ve solved, even your process of problem-solving. At the very least, when you encounter similar challenges in the future, you’ll have a reference for how you solved them in the past. Your blog post about how you fixed a particular issue might be helpful to someone else as well.
There are many options available for putting a resume and/or blog online. Sandro hosts his, mine, and a few others on a server at his house. But for those of you who don’t have a buddy to host theirs, here are a couple of readily-accessible free options:
There’s a ton of advice out there on what makes a great resume, so I won’t try to repeat it all here. You can simply put a version of your 1 or 2-page Microsoft Word resume on the web, or you can put your entire career up there. Having your own blog or website means you aren’t subject to any restrictions on length that a site like Monster or CareerBuilder might impose. Consider linking your resume to the websites of previous employers, technologies you’ve worked with, schools you’ve attended, and work you’ve done that showcases your skills (especially if it’s web-related). I don’t know if that makes it easier for Google to find you, but it does give recruiters easy access to details about you they might have to dig for otherwise. Doing what you can to make this process easier for them certainly can’t hurt.
Back on November 20, I attended a seminar at the Reagan Building on how healthcare in the U.S. could be improved through information technology. As an alumnus of the business school, and someone who’d worked in healthcare IT before, I wanted to learn about a part of the healthcare debate that I hadn’t seen much coverage lately. Dr. Ritu Agarwal gave the talk and answered questions during and after her presentation.
The main problem with healthcare in the U.S. could probably be summed up this way:
Despite spending more on healthcare than any other country in the world, our clinical outcomes are no better than in countries that spend far less.
Even more disturbing, of the 30 countries in the OECD, the U.S. has the highest infant mortality rate.
In the past 10 years, premiums for employer-based health insurance have risen 120%. Over the same period, inflation grew 44%, while salaries grew only 29%. So healthcare costs are increasing far faster than inflation (and our ability to pay for it with our salaries).
As far as healthcare IT goes, Dr. Agarwal gave the following reasons for the slow pace of adoption by healthcare providers:
Adding to the inertia point is the fact that healthcare in the U.S. has many stakeholders–patients, medical professionals, hospitals, pharmaceutical companies, insurance companies, and more.
Dr. Agarwal pointed to a number of countries with successful implementations of healthcare IT. They included Canada, Australia, and the United Kingdom. Australia in particular was singled out as being 5-10 years ahead of the U.S.
One thing I didn’t expect was that the Veterans Administration and the Department of Defense would be held up as native models of successful healthcare IT implementations. One key factor noted by one of the other seminar participants was that the VA and DOD systems were closed. Providers, specialists, hospitals, etc were all part of the government. This enables them to enforce standards, in patient records and other areas. Another point I considered later (which didn’t come up in the Q & A) was that the government model is non-profit as well.
Dr. Agarwal’s proposed solution to improving the current state of IT use in healthcare (as I recall it) was an regional exchange model. Healthcare providers in a particular region of the U.S. would choose a standard for electronic health records (EHR) and other protocols. Connections between these regional exchanges would ultimately form a national health information exchange. Building on existing protocols and technologies (instead of attempting to build a national exchange from scratch) would be the most practical choice.
For more information, check out the slides from the presentation.
It’s been a couple of years since I first learned about the InternalsVisibleTo attribute. It took until this afternoon to discover a problem with it. This issue only occurs when you attempt to unit test internal classes of signed assemblies with an unsigned test assembly. If you attempt to compile a Visual Studio solution in this case, the compiler will return the following complaint (among others):
Strong-name signed assemblies must specify a public key intheir InternalsVisibleTo declarations.
Thankfully, this blog post gives a great walk-through of how to get this working. The instructions in brief: