My current project is a simple solution, and looks like
ExcelExtractor
|---ExcelExtractor (class library)
|---ExcelDriverApp (console app)
I created the driver project in 2010 last night and checked the project in to SVN. This morning I pulled down my home work and added it to the 2008 solution at work. The two warnings I received were due to an invalid reference to the same library
Warning 1 Could not resolve this reference. Could not locate the assembly "Microsoft.CSharp". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. ExcelDriverApp
Warning 2 The referenced component 'Microsoft.CSharp' could not be found.
No compilation errors, just the warning. Run-time however it threw up all over itself
System.IO.FileNotFoundException was unhandled
Message="Could not load file or assembly 'ExcelExtractor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified."
Source="ExcelDriverApp"
FileName="ExcelExtractor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
FusionLog="=== Pre-bind state information ===\r\nLOG: User = COMPANY\\bfellows\r\nLOG: DisplayName = ExcelExtractor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\n (Fully-specified)\r\nLOG: Appbase = file:///C:/Src/Foo/Src/ExcelExtractor/ExcelDriverApp/bin/Debug/\r\nLOG: Initial PrivatePath = NULL\r\nCalling assembly : ExcelDriverApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.\r\n===\r\nLOG: This bind starts in default load context.\r\nLOG: No application configuration file found.\r\nLOG: Using machine configuration file from C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727\\config\\machine.config.\r\nLOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).\r\nLOG: Attempting download of new URL file:///C:/Src/Foo/Src/ExcelExtractor/ExcelDriverApp/bin/Debug/ExcelExtractor.DLL.\r\nLOG: Attempting download of new URL file:///C:/Src/Foo/Src/ExcelExtractor/ExcelDriverApp/bin/Debug/ExcelExtractor/ExcelExtractor.DLL.\r\nLOG: Attempting download of new URL file:///C:/Src/Foo/Src/ExcelExtractor/ExcelDriverApp/bin/Debug/ExcelExtractor.EXE.\r\nLOG: Attempting download of new URL file:///C:/Src/Foo/Src/ExcelExtractor/ExcelDriverApp/bin/Debug/ExcelExtractor/ExcelExtractor.EXE.\r\n"
StackTrace:
at ExcelDriverApp.Program.Main(String[] args)
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:
I cleaned the solution and rebuilt all, verified there was an ExcelExtractor.dll in that project's debug folder as well as an ExcelDriverApp.exe in that app's folder. So what's the story? It's really rather trivial, the project I created under 2010 is targeting the 4.0 .NET library. If I look at the 2010 project in 2008, it looks vaguely correct except the on the Application tab, my Target Framework: selector is showing nothing. 2008 can't target a 4.0 library and if I select 3.5, the project will compile just fine (I'm doing nothing 4.0 centric) and actually run this time.
Being a tinkerer, I needed to keep picking at this though, why I not seeing anything beyond those two warnings? As always, the command line is your friend although in this case, the Output window from my Build was sufficient
------ Rebuild All started: Project: ExcelDriverApp, Configuration: Debug x86 ------
Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
So the MSBuild is smart enough to default to 3.5 when the project contains an invalid ToolsVersion value but the JIT(?) isn't able to correctly tie that byte code in with the output from the project with actual 3.5 value. At this point, I realize I've spent far too much time digging around and I'm up against the depth of my knowledge of how the the whole MSIL/CLI/JIT process works. It's unfortunate too, I think I'm nerdy enough to want to do some heady reading on this stuff but I also have a deadline for getting this POC out and the simple fix is to select 3.5 and recompile.
No comments:
Post a Comment