So I've create a solution with multiple projects... one is for my website, the other for my data. I've added the reference and everything seems to be working just fine. Until now...
I recently created a model.edmx for a table and a stored procedure. When I trying and create a variable of that model, I get this error:
The type 'System.Data.Objects.ObjectContext' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
I'm assuming this is because I'm using multiple projects, I just don't know how to fix this!
Ah... just like having to add the reference to the other projects within the solution, I had to add a reference to the System.Data.Entity using that same right-click "Add Reference" dialog.
The project where you are trying to create a model object needs to have a reference to System.Data.Entity (as the error states).
Related
Why I cannot create Type Provider as *.exe file with [<TypeProviderAssembly()>] and [<EntryPoint>] inside?
When I try to reference such TP using #r #"d:\TP\bin\Debug\MyTypeProvider.exe", I see the following:
test.fsx(3,1): error FS3031: The type provider 'd:\TP\bin\Debug\MyTypeProvider.exe' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'MyTypeProvider' which cannot be loaded or doesn't exist. Could not load file or assembly 'file:///d:\TP\bin\Debug\MyTypeProvider.dll' or one of its dependencies. The system cannot find the file specified.
I need to have a type inference runtime in separate process, because it should be 64bit (unlike 32bit VS process). But I want to pack all things into one file, reference it from VS and start as external process.
Perhaps there's some good underlying reason for always looking for DLLs instead of EXEs, but I suspect this may be an arbitrary limitation.
I can get things to work in FSI if I supply the assembly's full name to the TypeProviderAssemblyAttribute constructor (e.g. [<TypeProviderAssembly("MyExe, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null")>]), but IntelliSense doesn't work and I can't use the TP from other projects. Consider filing a bug with the team - but it would probably help if you could justify why you need an EXE instead of a DLL for your scenario.
In my ASP.NET MVC application, I have the following setup:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;extras"/>
I have referenced assemblies located in the extras folder in the views and they have worked perfectly (using <%# Import Namespace="myNameSpace" %>).
My questions
What happens when that line is called?
Where is the assembly loaded?
Why is it that I can't overwrite the assembly located in the extras folder that contains myNameSpace with a newer version? (I get an error saying that the assembly is "open" in another program)
Is there a way to overwrite the assembly with a newer version without having the application restart?
1) Import doesn't actually do anything at runtime. It's a compile-time convenience that just lets you refer to types using their unqualified names such as Environment instead of System.Environment.
2) The assembly is loaded using normal assembly probing rules. The CLR checks various locations before these private probing paths so it's important to keep that in mind. If you reference a strong-named assembly and expect to find that assembly in a private probing path, an assembly with the same strong name (name, version, public key, etc) in the GAC would be preferred. This can sometimes lead to unexpected behavior and is usually caused by hard coding an assembly version in your AssemblyInfo.cs and forgetting to update it.
3) Once loaded, an assembly cannot be unloaded without unloading the AppDomain. But ASP.NET uses "shadow copying" which means assemblies are copied to a temporary path before being loaded. This should leave the original assembly unlocked and able to be overwritten. Off the top of my head, I am not sure why you'd be getting the error about locked assemblies. In a normal Windows application, this would be totally normal and expected. But ASP.NET is designed so that you can overwrite content, code, assemblies, etc while the application is running, which leads to #4.
4) In practice, no. Because an assembly cannot be unloaded, there is no way to upgrade an assembly without the web application being restarted. Technically speaking, you can load multiple versions of an assembly but this would not give you the desired results. Any compile-time references would still reference the old assembly and you'd get all kinds of invalid cast exceptions if you tried to use the new assembly. But as I said in #3, with ASP.NET upgrading assemblies is supposed to be as simple as replacing the files and should happen automatically. You shouldn't have to restart IIS or worker processes manually.
The following links may be of interest.
How the Runtime Locates Assemblies
Best Practices for Loading Assemblies
Shadow Copying Assemblies
Unloading Assemblies - Suzanne Cook
UPDATE
After reading a bit more on shadow copying, I think the reason you might be seeing the issue of locked assemblies in the extras folder is that ASP.NET probably only specifies the "bin" folder for shadow copying.
I think this is the same as a using statement in C#, it basically means that the namespace's classes are now available to be used in yoru page.
The assembly will be loaded into memory probably by the aspnetwp.exe process
If the assembly is currently being used you will get this error message
A restart is the safest way I know of doing this, you could use dependency injection or late binding to achieve the same result. I would jsut wonder why you would want to switch an assembly while the application is running?
Is it possible to import a namespace from an assembly that is not in the bin folder?
I'm using ASP.NET MVC 2 with MEF to pull controllers out of the assembly.I was able to get everything working, however, strongly typed views can't recognize the assemblies' objects unless the assembly is in the bin folder.
Strongly typed view means knowing the object type at compile time. In order to know the object at compile time the assembly containing the class needs to be referenced. Referencing assemblies in an ASP.NET application is done by putting them in the bin folder.
If you use reflection to load assemblies from some other non-standard location, types will be known only at runtime and you cannot use them as models for strongly typed views.
If you want to load assemblies from somewhere else than the bin folder at runtime, you may do so by calling the appropriate method through the AppDomain.
I like the new Add View dialog that was released with RC1. If you specify a view data class, it generates a scaffolded view for you. It seems to work fine with classes defined in projects within my solution. Some of my domain classes inherit from a base class that is defined in an external assembly (and referenced in my web project). I get an error when I specify one of these domain classes. Visual Studio is reporting a TypeLoadException on the external base class.
I did a little debugging with ProcMon and found that it was looking for the base class DLL in, among other places, a temporary folder. That folder did contain the DLL containing my derived domain model class. I did not see the base class's DLL. So for fun, I copied it there and voila, I could add the view.
Is this a bug?
Yes this is a bug. Please file it on http://codeplex.com/aspnet
you actually forgot to add the Web.Config file on the View Folder.
See this small article : http://www.graytechnology.com/Blog/post/ASPNET-MVC-strongly-typed-view-error-Could-not-load-type.aspx
It got me scratching my head quite a bit as well in my current project! :)
I have a project with 2 subfolders in the App_code folder, one for VB and one for F# (C# files are in the root). I can access the VB classes just fine (via the namespace) but not the F# code. Has anyone had a problem like this and if so how did you fix it?
Addendum:
F# code that is not in the App_Code folder runs just fine. Is is as if the compiler and IDE do not see the F# code that is in a subfolder of the App_Code folder called FS_Code. I have added the codeSubDirectories element
<codeSubDirectories>
<add directoryName="VB_Code"/>
<add directoryName="FS_Code"/>
</codeSubDirectories>
The VB code in the VB_Code subfolder compiles just fine.
Note that by default, if you don't declare a namespace or module, top-level F# code ends up in a module with the same name as the filename. See the first part of
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!444.entry
for details.
Step 3: Profit!!
Seriously, just placing a F# source file under App_Code is not gonna do anything.
What preparation tasks have you done so F# code can be compiled by the ASP.NET application?
Perhaps check out
http://cs.hubfs.net/blogs/tomasp/archive/2008/03/08/aspnet_in_fsharp.aspx
Open up the actual generated assemblies via Reflector - see what the actual namespacing is.
I believe that adding the <compiler ... /> configuration element for the F# language to the web.config should help (see the link Brian posted) - however, I doubt you'd see anything in the C# IntelliSense. However, it's not clear to me how you can reference code in one language from the code in the other...
You can also check out this link: http://shailkpatel.blogspot.com/2007/10/multiple-programming-languages-in.html
It's been a while since I asked this question but I think it ended up being a problem with the F# compiler not being in $PATH (I had it installed in a non standard location).