I have a solution with several projects in it, one of them being a website. The website has references to five web services, which are being run on our own servers. When building the website with VS 2010 I get the following error:
Validating Web Site
App_WebReferences/VpService/(1): Build (web): Reference.svcmap: Could not load file or assembly "Konzeptum.BL.Base, Version=2.6.0.0, Culture=neutral, PublicKeyToken=null" or one of it's dependencies. The system cannot find the file specified.
The service that produces this error changes on every build. The apparently missing dll cannot be found on any of the machines I looked at, it's not even present on the servers running the services. The services however have references to some APIs which in turn have references to the dlls Konzeptum.BL.Telerate.Provisioning, Konzeptum.VO.Base, Konzeptum.VO.Telerate.Provisioning. My guess is that these dlls make use of the missing Konzeptum.BL.Base.
I can compile each project just fine (the services, APIs etc.) just the website has this problem. I have tried updating the service references, deleting and re-adding them, nothing. The only solution I could find online (and that kind of works) is deactivating the reuse of types in the Service Reference Settings for each service. I uncheck the three dlls mentioned above and reuse all other types.
Now however if I build the website I get errors that there are ambiguous references between types provided by the service and existing ones (e.g. FileInfo from System.IO) or errors that some data types cannot be found. These missing types however have nothing to do with Konzeptum stuff, they are defined by the services themselves. Luckily for me these errors pop up very late in the build process of the website, so that most of it is usable.
What could be the cause of these problems and how can I solve them?
Thank you for any help.
Edit:
Maybe it wasn't clear before, but this problem seems to occur only on my machine, two other developers don't have any problems building the website (and we're using the same tfs repository). The servers running the live system don't have any problems. But the missing dll is not present anywhere, so I can't just copy it over. The Assembly Binding Log Viewer isn't of much help either, in the entry for Konzeptum.BL.Base under Calling assembly it just says (Unknown).
Ok, after searching for differences between my machine and those of the other developers I found one that I thought shouldn't matter at all. They had .NET version 4.0 installed vs. version 4.5.1 on my PC. So after uninstalling 4.5.1 and installing 4.0 the problem went away. I can now successfully compile the whole solution without any errors. Why that is - I have no idea. The projects in the solution all target 4.0, so I thought running them under 4.5.1 should be no problem, but I guess not. I even went through the list of changes between 4.0 and 4.5/4.5.1, but I couldn't find anything that relates to my problem.
Thanks to anyone that tried to help.
Related
We have a C# .NET website which was developed and maintained by a third party. I'm due to take over the general upkeep soon, so am trying to get a system going where I can maintain a local copy and deploy updates to the website. We need to make it work for two of us to work on for at least another month, after that I'm on my own.
We have an SVN of source, and an SVN of production published code. I can pull the solution and after some faffing I can make it build and run without problems locally. I'm using Visual Studio 2015, the target framework is 4.0.
I can update cshtml files, build, publish locally, and then copy these files over the website published version and it runs fine.
However, the bin/dlls that are produced, if copied into the website version, produces this fabulous error:
http://website.com/Error/InternalServerError?aspxerrorpath=/
Server Error in '/' Application. Runtime Error.
Description: An exception occurred while processing your request.
Additionally, another exception occurred while executing the custom error page for the first exception.
The request has been terminated.
If I copy back the dlls from the original, it works fine.
If I don't modify the code, but just build and publish the project, my dlls are still different sizes from the website versions.
The developers are using Visual Studio 2012, is this a factor? Why are the dlls for my local version (that runs fine) different, if I download the source and build/publish it with no changes?
The dlls in question by the way are a single one for the website itself, website.dll say, and one for 'objects' that they've dumped a load of functions into for doing various things, objects.dll, these are the only two I'm trying to copy over - all the other dlls match in size between my and the website versions.
I'm pretty new to this so may be making some fundamental mistakes here, but if I am, then our developer isn't picking up on them. I mean, I'm kind of not surprised that they're different, surely you need to deploy the whole project, and not just drop some dlls into an existing published folder? My developer is saying that's the only way we can do it...
Any tips of things I can try?
Thanks in advance.
Well, after a LOT of trial and error, I finally found a solution that works for me, for the moment:
Using nuget package manager, I reverted to Microsoft.AspNet.Mvc version 4.0.40804 for the project in question. This seems to have updated all the references and runtimes back to the 4.0.0.0 that the project was built using.
When I build, publish, and copy across the main dlls, the site now runs, rather than showing the 'Server Error in '/' Application. Runtime Error'
One thing, are there security implications for running such an old version? Maybe that needs to be a new question...
Thanks for all the help.
I am helping out with a project that a contractor worked on previously (so I don't have a lot of history for it).
The project builds fine, but when we try to perform some operations, we get a runtime error indicating that System.Management.Automation.dll could not be found.
As a troublshooting measure, we manually installed the dll into the installation directory. We then get an error indicating failure to load Microsoft.Management.Infrastructure.
As nearly as I can tell, these dlls are present in the Microsoft Management Framework download, and possibly in Powershell 3.0.
My question: What is the smallest package that these dlls are a part of, and what is the best way to deploy them for a production software release?
Edit
Just to be clear -- I am not looking to hack/frankenbuild by deploying just those dlls "naked", I am trying to identify the correct redistributable package for those dlls. I just can't seem to work out which one it is.
Edit
If it helps, the nature of the code that we are running is to programmatically create an exchange mailbox.
I think you can't legally redistribute any of those two DLLs alone (discussed for example here for the Automation, you can also check the "Redistributable" section on MSDN for those namespaces). You will have to make sure the target machines have PowerShell and the Management Framework.
Just in case anyone else runs into this problem: We ended up resolving the issue by deploying the Windows Management Framework 3.0, which includes the necessary assemblies. http://www.microsoft.com/en-us/download/details.aspx?id=34595
I'm seeing the following error crop up occasionally (seemingly at random) on my web application. We are running Windows Server 2008R2, IIS 7.5, MVC3, .NET 4.5.
It's the same error every time: CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.Binder.BinaryOperation'
When this error occurs, it can take anything from a restart of the application pool, to the re-install of our application itself, to fix it.
The error occurs on brand-new VM images (no previous installation of our software), as well as machines that have previously had our software installed on it. The error can occur upon the first run of the application, or when the application has sat long enough for the IIS application pool to recycle the worker process (so it seems).
This is becoming really difficult to deal with, as I've done a ton of research on this error, and tried multiple solutions, with no luck. Also, the random frequency at which the error occurs has made it very hard to troubleshoot. Any insight into this issue, or ideas on possible solutions, would be greatly appreciated. I'm willing to try almost anything at this point.
This looks familiar. If I recall corectly I had to delete the bin directory and rebuild because older versions of dlls were floating around and this class was introduced in .net 4.0
After some research, this site seems to agree: http://our.umbraco.org/forum/using/ui-questions/20474-Missing-compiler-required-member-MicrosoftCSharpRuntimeBinderBinderInvokeMember
Try Forest Cheng Answer:
What version your .NET Framework is?
The ASP.NET MVC 3 run-time components require .NET Framework version 4 and Visual Studio 2010 or Visual Web Developer 2010 Express. Want more information, please look at ASP.NET MVC 3 Release Notes.
Compiler Error CS0656 can be caused by the follow problems:
Your installation of the common language runtime is corrupt.
You have a reference to an assembly that defines a type that is also found in the common language runtime. However, your assembly's type is not defined the way the C# compiler expects.
So check your references to ensure that you are using the correct version of the common language runtime.
We used to have these compilation errors occuring randomly back in the day a long time ago with .net 1 and beyond. This required deleting the contents of the temporary asp.net folder, and finding other rogue dlls that were hanging around, even inside a visual studio cache. In general, flushing the temporary asp.net folder will do it.
Make sure you find all the dlls - the bin folder too obviously, and remember that the dlls are executed from a shadow directory. That is why i recall (also from a long distant memory) that there is a connection to the default appdomain which assemblies are loaded into, especially if you then go loading "the same assembly " but from a different file location.
Make sure you have Microsoft.CSharp reference added in your project.
I added it to my test project and the error disappeared.
I am working on a Web Application on a Windows 8 64 bit machine using multiple existing libraries. I want to use two C# DLLs referencing one native DLL. Both C# DLLs are compiled for 64bit usage and tested in test applications.
My web application references both C# DLLs and is supposed to run on IIS 8.
I added the two C# DLLs as references to the project and the native DLL manually to the bin folder of the web app. Whenever I build and run the solution I get the exception shown in the title.
I know that this is a sign for a problem regarding 32 bit and 64 bit code running in one process. Therefore I tried all different build configurations but the result never changed.
I created a console application doing exactly what I'm trying in the web app and it worked flawlessly.
The Web application with the exact same settings however throws the exception, this is what is really confusing to me.
What I tried so far:
Change application pool setting to "enable 32-bit applications"
Build all DLLs with Any CPU, 64Bit or x86 target
Check the corflags of all DLLs
I can provide an export of the project to everybody willing to help me get this configuration running!
I really appreciate every bit of help!
I presume you tried with setting Target Platform (Build option in project properties)?
Also, take a look at this article:
http://www.codeproject.com/Articles/383138/BadImageFormatException-x86-i-x64
I got the same issue on my application. It was fixed after I perform the following:
* Granting permission for the "Anonymous" user in my web site folder.
* Changing the application pool from ".NET v4.5 Classic" to ".NET v4.5".
All I can offer is some help in determining what isn't loading. If it's a dev server it might be worthwhile to install the appropriate sdk to use the Fusion Log Viewer. If that isn't an option you can turn on assembly binding logging from the registry as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogFailures"=dword:00000001
"LogPath"="c:\\bindFailureLogs\\"
just be sure to turn it off when you're done, there is a performance penalty using the assembly bind logging. Make sure the folder exists before you enter the registry key and recycle the application pool of the application for the logging to start. This will provide you a detailed list of what dll (or dependency since it's not always readily apparent if it's a dependancy or the dll listed in the error message) didn't load and where it tried to load it from.
Your partitioning of the applications fixing the problem suggests that there are multiple dependencies on the assembly targeting different versions and since only a single version of an assembly can be loaded into an app domain some dependency isn't being satisfied. For managed assemblies you could use an assembly binding redirect, but I don't know what the unmanaged equivalent of that would be if it even exists.
We have an Entity Framework project with several models set up using .NET 4 and VS2010. Then we have several projects that need to use this entity project. We successfully compiled the EF project into a DLL. We have also successfully added the EF dll reference into multiple projects which is working great.
The problem is now that we have several programs (ASP.NET and console apps) that reference this EF dll and the dll is copied locally for each calling program, when we make a change to the EF dll, we then have to go into each and every project and replace the EF dll with the new build.
I've done a lot of searching for sharing libraries and even EF projects across multiple projects. While I have found several, I can't seem to find a good example that I can make work for my situation or that isn't so old that it's irrelevant.
That is the general issue I'm having. To give a better idea of the issues I'm encountering, I will focus on one particular project. This is an ASP.NET webform project for in intranet. If we add the EF dll reference and allow the project to copy the dll locally, the EF works fantastically. However, because we have multiple project we now need to try and centralize the EF dll somewhere where it can be shared by the multiple processes. I am not trying to set this up so that one EF dll is accessed across multiple server. I am happy to install a copy of the DLL on individual servers if necessary.
My desire is to create a "common libraries" directory on each server, simplified example "C:\OurLibraries". We would then put or EF dlls (and maybe others later) into this folder and allow the various programs/processes to access the common copy of the EF dll. I've made sure the "local copy" of the EF dll has been removed from the intranet project and added a reference to the "C:\OurLibraries\OurEF.dll" file. Everything builds fine and the intranet project works fine until it tries to display a page that has references the EF and then displays an error message:
"Could not load type 'EntityNS.ProductDBEntity'."
If I turn on "local copy" in the reference, the intranet site works fine again. I cannot seem to find that magic setting that will allow me to share the EF dll.
I have tried the following things based on various posts, but with no success:
Signing the assembly and adding to the GAC. Experienced the same issue as having it in "C:\OurLibraries"
Adding the "C:\OurLibraries" directory to the PATH environment variable.
Changed my connection string for the EF in my intranet web.config file to remove the "OR's" from the string:
/Ecomedate.csdl|res:///Ecomedate.ssdl|res:///Ecomedate.msl;provider=System...
to
;provider=System...
(based on this post: Sharing Entity framework objects across projects?)
I've spent many hours working on this and searching forums and posts. I know there has got to be a way to do this otherwise code reuse and DLL sharing seems useless, so any help you can suggest would be appreciated.
Here is are additional efforts that I have made and in response to some of the post so far.
Also here is what I have experienced with the GAC so far.
- on a computer with VS2010 installed, the gacutil is located in C:\Program Files\Microsoft SDK... and from forum on questions "Where is the gacutil" the general tone is that gacutil is now considered a dev tool and not intended for use in prod environments. Gacutil is not part of the Server 2008 or .Net 4 framework, so there are several suggestions on how to deploy and deal with GAC dlls
first, the old way of installing, using the gacutil, but by using psexec to copy and call gacutil on the production server. I can get psexec to run the gacutil from a local dev box to a prod server and get a return code of 0, success, however I cannot find a way to actually view that it is installed on the production server, because there is not gacutil on prod server, I can't use someting like gacutil /l DataEntity.dll to view info on installed dll...if it even installed correctly.
I tried copying the gacutil.exe and gacutil.exe.config files to production server to try and run from there. While the program run and gives the version number of the gacutil, it doesn't respond to any command line switches such as gacutil.exe /i DataEntity.dll or gacutil.exe /l DataEntity. It just displays the gacutil version info again and stops.
Someone suggesed on a forum to installing the Microsoft SDK on the prod machine. While I might have to consider this due to lack of success so far, I really don't like the idea of installing an SDK on my production evironments.
I tried to find tools such as the Remote GAC Manager to view and manage, but the last development on that opensource project was 2008, so when I try to use it to veiw the GAC, it is wanting to show me c:\Windows\assembly gac dlls, but .NET 4 now uses C:\windows\Microsoft.NET\assembly to store GAC dlls, so I can's seem to find any way to view or maintain DLLs on the remote production server's gac. If I run a dir DataEntity.dll /s command at c:\windows in the command prompt, I find the dll embedded in the C:\Windows\Microsoft.NET\assembly\GAC_MSIL directory, but if I try to look at the file through explorer in C:\Windows\Microsoft.NET\assembly\GAC_MSIL, I cannot see the dll, so I cannot find a tool that allows me to manage (install, list, uninstall) the DLLs in C:\Windows\Microsoft.NET\assembly\GAC_MSIL on the server 2008 production server.
There was a suggestion to install dlls into gac via drag and drop. I am trying to automate our deployment process, so having to manually drag and drop doesn't make a lot of sense. Does a copy to the C:\Windows\Microsoft.NET\assembly\GAC_MSIL directory work too? I've tried it, but again since I cannot find a tool that will let me see the installed/registered DLLs I can't tell if it worked or not.
another suggestion was to create an installer that would just install into the GAC. I tried this method and ran into a couple of issues. First it was a very manual process. I could not figure out how to get it to uninstall the old dll from GAC and then install the new version of DLL in gac; it kept insisting that I uninstall the previous installation first. Second, when I tried to uninstall the dll, it kept saying that it was in use by another application. I tried restarting and then uninstalling it, but no go. I finally figured out it was IIS and had to shutdown IIS, uninstall, restart, install, and then restart IIS. This is a pain in the but to try and automate.
Seems like there should be a better way to deploy dlls to a production environment into a shared directory. I simply want to try and put the DataEntity.dll in a c:\MyLibraries directory and have the processes access that one copy of the DLL. Microsoft does it with the C:\Program Files\Common Files, so it should be possible, but I have now spent days trying to find a way that works that would considerabley reduce the maintenance efforts imposed by the GAC or installer options, reduce the number of duplicate dlls, and avoiding overlooking replacing dlls if allowed to 'copy locally'.
the best solution for your problem is using Web Services.web services are created for this purpose.You can build a WCF service library and then use it's methods in all of your projects.
Good Luck
The GAC approach is probably the closest one to what you are looking for. Since you were unable to get the GAC working, you should double check to makes sure you followed the instructions for installing in the GAC.
This may seem pretty "out-there" as a solution but we are considering using a Git Repository to do a remote publish to multiple servers, the Git repository would be committed with the latest DLL(and only the DLL), then pushed to each production server/application server.