Fervent Coder

http://www.infoq.com/news/2008/08/.NET-3.5-SP1-Runs-Managed-Code

In the past, one could not run managed code from network shares due to security reasons. That feature was introduced in .NET from the beginning to prevent security attacks coming from network locations. The feature did not resolve the respective security threats because unmanaged code always was allowed to run in such a circumstance.

A pool organized by Brad Adams, Program Manager at Microsoft, shows that many people would like to have the possibility to run managed code from network shares. Microsoft responded to the general request enabling the feature in .NET 3.5 SP1.

Dru pointed this out to me and some others today.  I am not sure where I stand on this one yet (because I am compulsive about security).  To look at why they did it makes sense (from a consistency standpoint).  If you are running something from a network share you are inside your network.  Usually if you are running something on the network, it is because you want to run it. And if you can get to it, you can give yourself permissions to do it (provided you have the right privileges).

What happens when you don’t want to allow other people in your network the ability to run something (and you basically have not given them the privileges to run CasPol)? Hmmmm...

I guess that is where the application has its security and security checks (which is a good practice and what you would have to do with unmanaged code).

I am kind of on the fence with the change because I am used to CasPol and limiting and controlling permissions.

What are your thoughts?

This threw me for a loop today. You can't call a PowerShell function with commas "," or parentheses "()" and have it believe it goes to both parameters.  Try running the following and see what your output is on every line call to "foo."

function foo([string]$a, [string]$b)
{
   Write-Host "a:", $a, " b:", $b
}

foo("A", "B")
foo "A", "B"
foo "A" "B"
foo("A", "B") "C"

rm function:/foo

You may find you get different results than you may first expect. I did.

You may run into this at some point. TFS Team Build may not deploy some assembly file you needed.  If you look through the logs, you will see something like this (cleaned up for readability):

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Vbc.exe
/noconfig
/optionstrict+
/rootnamespace:Company.Project.Console
/doc:obj\Release\Company.Project.Console.xml
/define:"CONFIG=\"Release\",TRACE=-1,_MyType=\"Console\",PLATFORM=\"AnyCPU\""
/reference:..\libs\Castle\Castle.Core.dll,
..\libs\Castle\Castle.DynamicProxy2.dll,
..\libs\Castle\Castle.Facilities.NHibernateIntegration.dll,
..\libs\Castle\Castle.MicroKernel.dll,
..\libs\Castle\Castle.Windsor.dll,
c:\BuildLocation\Company.Project\Project_Candidate\Binaries\Release\Company.Project.dll,
c:\BuildLocation\Company.Project\Project_Candidate\Binaries\Release\Company.Shared.dll,
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727System.Data.dll,
C:\WINDOWS\Microsoft.NET\Framework\v2.0.5072\System.Deployment.dll,
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727System.dll,
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
/main:Company.Project.Console.Program
/debug:pdbonly /optimize+
/out:obj\Release\Company.Project.Console.exe
/target:exe Program.vb "My Project\AssemblyInfo.vb"
/warnaserror+:41999,42016,42017,42018,42019,42020,42021,42022,42024,42025,42029,42030,42031,42032,42036,42104,42105,42106,42107,42108,42109

Target _CopyFilesMarkedCopyLocal:
    Copying file from "..\libs\Castle\Castle.Core.dll" to "c:\BuildLocation\Company.Project\Project_Candidate\Binaries\Release\Castle.Core.dll".
    Copying file from "..\libs\Castle\Castle.DynamicProxy2.dll" to "c:\BuildLocation\Company.Project\Project_Candidate\Binaries\Release\Castle.DynamicProxy2.dll".
(MY NOTE: This is missing a "Copying file" for Castle.Facilities.NHibernateIntegration.dll)
    Copying file from "..\libs\Castle\Castle.MicroKernel.dll" to "c:\BuildLocation\Company.Project\Project_Candidate\Binaries\Release\Castle.MicroKernel.dll".
    Copying file from "..\libs\Castle\Castle.Windsor.dll" to "c:\BuildLocation\Company.Project\Project_Candidate\Binaries\Release\Castle.Windsor.dll".

What the heck?  I know I have this file marked as copy local. It copies it when I build locally. That is the default setting when adding a reference to have it copied local. What's the deal?

Who knows why it does this (or doesn't in this case), but if this ever happens to you, it is a simple fix. Some simple switch may not be being picked up or you need to get an explicit switch into the solution.

The Fix

1. In Visual Studio, go to Solution Explorer on the project that is having the issues with the referenced assembly.

2. Open your References folder and find the item that is not making it into the build folder during a team build (we are going to pretend that is log4net here). NOTE: In Visual Basic to see the References folder in Solution Explorer, you need to select View All Files after selecting any item in the project in Solution Explorer.

3. Right click and select [Properties]. Find [Copy Local].

4. Change [Copy Local] to False.

5. Change [Copy Local] back to True.

6. Check into source control any changes that have occurred.

7. Try your team build again.

8. That's it.