We Keep Coding

How check if an executable is compatible to the installed .NET version

I'm a software tester. I was given an executable to test on a given machine. In the test the executable behaved strangly which could not be explained by anybody.
After a lot of research and debugging I found the cause: The executable that was built for .NET target framework 4.6, but the machine was equipped with .NET 4.5.
This produced some "MissingMethodExeception" for even trivial methods like "string.Format()". Some try-catch caught these exceptions, but treated them in wrong way because nobody had expected them to occur.
A likewise issue has been described here:
Method not found: 'System.String System.String.Format(System.IFormatProvider, System.String, System.Object)
My questions:
Isn't Windows meant to warn me when I'm trying to run an executable that cannot be run properly since the necessary .NET version is not available?
What is the best practise to deal with this problem in general?
(I would have expected something like a checkbox "Dont execute if target network is not available" in VisualStudio?!)

Isn't Windows meant to warn me ...
You'll certainly should get a warning, not from Windows but from the CLR. The dialog looks like this, clicking Yes automatically gets the required framework version deployed and installed on the machine. The CLR performs this check by looking for the [TargetFramework] attribute embedded in the assembly. As noted, run ildasm.exe to verify this attribute. With the expectation that it is either missing or has a low enough value so the dialog does not trigger.
What is the best practice to deal with this problem in general?
It is procedural mistake, the assembly was built wrong. You know with high confidence that the compiler used reference assemblies that are only appropriate for .NET version 4.6. That has to be traced back to the machine that built it, most likely to be a build server. It was not setup correctly, the kind of mishap that is so common when the build engineer cut corners by avoiding using a licensed copy of Visual Studio. Or by favoring freeware tooling, Jenkins is a common scourge.
Beyond getting the [TargetFramework] attribute wrong or missing, this particular mishap is particularly easy to induce. All it takes is using the assemblies in c:\windows\microsoft.net\framework as reference assemblies instead of the proper ones that require a targeting pack and are installed in the c:\program files (x86)\reference assemblies directory. This Q+A has more leads.
Fixing a build server tends to have lots of resistance points, best thing to do as a tester is to file a bug report. You also want to write one for the broken catch-em-all exception handling that made the problem so difficult to diagnose.

To answer the questions:
No Windows is not meant to warn you that the desired .Net Framework is not installed to run this executable. However, Windows will log the error or application crash information in Windows Event Logs.
Re second question...
In general, executables are delivered, deployed or published using Installers. Installer can be configured/written such that they will warn user if .Net framework(required by the exe/dll) is not installed.

Server Error in '/' Application after updating a dll in a C# .NET website project

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.

C# com reference publish crash

I've never used C# before writing this app, and I loathe Visual Studio, so please bear with me if I am just being daft.
I've created a nice little utility that automates a number of painful processes at my job. I've presented it to a large number of people, including a number of people overseas who are keen to use it.
The only issue is... I cannot get the application to run on any machine besides my own. On any other machine, the application crashes immediately upon start.
I've positively ruled out any issues regarding .NET installation in the client machine by packing the application in an installer which installs the proper version of .NET if need be.
As of now, my thoughts are that I am handling packing my two COM references incorrectly or that the application is dying from a security exception.
The application utilizes the COM Excel reference as well as one other COM reference that any client running my app will have installed on their machine. I have attempted to both distribute the application relying on Visual Studio to work magic and pull needed references, and also to force the references to "CopyLocal". Isolating the references failed, but I'm not sure if that is necessary or not.
Does anyone have any clues as to what the issue could be? Don't hesitate to ask me for clarification on anything.

You are facing some deploy problem. Even if it is true that copying the assembli and its used dll on the target machine typically work pretty well with .NET you are in a situation not exactly that simple.
First of all:
nsure target machine have the .NET framework installed in a version compatible with the one you use for your program ( ie greather than or equal )
ensure the proper COM objects are present and registered on the target machine. And this is the tricky part.
Since you are using excel, try to install on the target machine the Primary interop assemblies ( PIA ) for office. This will probably solve your issue.

Sharing Entity Framework Library across multiple projects

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.

How to handle build breaking external dependencies with a Continuous Integration server? (Ex, Crystal Reports with TeamCity)

I'm new to using continuous integration and have decided to go with TeamCity. One issue I have is that my code is not compiling due to a missing dependency.
(8, 7): error CS0246: The type or namespace name 'CrystalDecisions' could not be found (are you missing a using directive or an assembly reference?)
So, I'm not quite sure what is the proper thing to do here.
Do I install the Crystal Reports
redistributable and just let it sit there forever?
Do I set up my
build so that it installs Crystal
Reports before compiling and
uninstalls after all the tests are
complete?
Some other option I
don't know about?
Option (1) seems like it might be an issue since I could have multiple projects that need different versions of Crystal Reports and perhaps I can't have them all installed. Option (2) seems like it might be possible through the command line. I'm guessing this is the normal way to do this?
Thanks

To answer your question succinctly, you should install the redistributable on every box that is expected to compile the codebase, including TeamCity build agents, and leave it there indefinitely (you should, from that point, only have to touch that package again to update it to a later version as your application may require).
Usually, the TeamCity server (and/or its build agents if using a distributed CI model) needs to be set up with a simplistic development environment and/or an installation of the software. Put another way, the build agent will need the same resources that the dev environment would need in order to compile the application, except for a full install of the IDE (you're probably using msbuild or nant instead), for exactly the same reasons that the dev environment needs the resources. Such resources include, but are not limited to:
The codebase itself; all source code, config files and content/embedded resource files.
The targeted version of the .NET Framework, and any other version you wish to support explicitly (such as 3.5 when you target 4.0)
External libraries such as ORM and IoC frameworks, NUnit, custom data providers such as SqLite, and yes, redistributables such as Crystal Reports. This includes GAC registration as necessary.
Proper folder structure for inputs, outputs, assembly references, etc. identical to the dev environment.
The easiest way to ensure this is all present is to build it into your solution architecture where possible.