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.
Related
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.
I have made a Windows Form Application in C# using Visual Studio 2012. Can I publish this as a portable application to windows machines ?
P.S. portability here I am referring is working with any Windows( preferably windows 7 or 8 ) machine without installation and .net framework
Yup.
All you need to do is sheep your bin folder. It has your executable and all dependencies.
No installation will be required.
Just bear in mind that in order to be really portable, you will need to make sure that your application does not modify registries or computer configurations.
(from wikipedia:)
A portable application (portable app), sometimes also called
standalone, is a program designed to run on a compatible computer
without being installed in a way that modifies the computer's
configuration information.
You can if you do not have any dependencies, e.g. you have only the .EXE. If you have some .dlls you can use ILMerge to merge them into one .EXE
Depends on what you understand under portable. Avi's answer certainly works, as does ILMerge, but there's also the one file, no installation needed approach to portability.
I tread carefully because I don't want to advertise any application or another, but apart from taking the entire /bin folder, I've played around with Cameyo in the past and that seems to do a pretty decent job at virtualizing (and rendering portable) most applications as long as they aren't too large (or maybe have too many dependencies on what have you, not sure). Alternative tools may exist, I haven't researched any of them recently and neither do I prefer or affiliate myself with any of them.
Seems to work fine for your average app. I've tried to virtualize Visual Studio, that was fun. Big no-no. Who knows, it might suit your needs. It still doesn't take away the need for a .NET framework installed on the target machine though. As I mention in comment, that might be something for .NET Native (and, at time of writing, the future).
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 searched around but I could not find anything on this.
I have programmed a c# application in VS 2010, targeted to .NET Framework 4.0. It has a .DLL and a few config files which I have being copied to the output directory upon compilation. It works great on my computer, I have .NET 4.0 Extended and .NET 4.0 Client installed. I set the build configuration to "release" on "any CPU".
After it compiles I copy all the files from the release directory to a folder on a shared drive, so that multiple computers on the network can execute it. When I execute it from the computer that I used to develop it, it runs great. When others try to execute it starts but just shows a small blank form, and that's it. I make sure that they have .NET 4.0 installed (Both Extended and Client, though I think the full version is what is really required).
I can't for the life of me figure out why it does this.
All machines are running 32 Bit Windows Vista SP2.
Any thoughts? Much appreciation for any help.
It can be a lot of things. First, like one comment, you should do a quick Deployment project and try to install on another computer to see how it work.
If you can't do that, here a couple of things to check:
It can be a network permission problem. I've seens an .NET application that could not be executed on the network for x reason but worked on the desktop. To check, make sur your user copy it on their computer before executing.
I don't think it's a .NET problem because it wouldn't let you start the application.
My guess is that one of your control/library (the one that is not showing) does not have the proper reference when run from another computer. To check, run the application "Dependency Walker" (you can find it on google) and see what DLL are missing from other computers.
That's all I can think for now ! Good luck! You just have to use ellimination method and you will find the problem.
We are working on deploying a very custom application.
The application is the main program (and only program) that will run on the PC, but it depends on multiple 3rd party installers that must be installed via separate setup programs. Some of these are standard MSI, install shield, other outdated setups, etc.
On top of that we must deploy SQL Server Express 2005, install IIS if it is not found and setup a website.
Our final end user deploying this will be a person with technical experience on a new "out of the box" PC with XP SP3.
What is a good option for developing this? WiX? Visual Studio setup projects may not cut it. There is also the issue of somehow running other MSI's while an MSI is already running.
Would it function better as a standard C# application that requires .Net to be preinstalled? Then it would merely prompt for a few options then run several installers I suppose.
Any thoughts? We'd prefer to stick to C# .Net.
Doesn't XP SP3 already have a .NET runtime installed?
If your end user is someone with technical experience then it seems reasonable to sacrifice some of the "wizardness" of an MSI package for the flexibility of something a little more raw, such as a Ruby script, Powershell script, or .NET console or Winforms app.
This comes down to the benefit vs. cost.
If this is only to be run on a single or small number of target PCs and you have the ability to support the install (even remotely), I would recommend going to a manual install for any 3rd party dependencies.
It will be much easier to provide each package's installer with written instructions and provide than to write/test/debug (and probably still support) a complex, fully automated installer that will only be used once or thrice.
If there will be many installations, the automation will give more benefit.
There is an installer product called Inno Setup that might suit your needs. It allows for custom scripting so you can detect whether all of the dependencies are installed.
If some of them are not installed then with some scripting the installer can download and install the 3rd party dependencies before installing your app. Some help with that can be found at the Code Project article. (http://www.codeproject.com/KB/install/dotnetfx_innosetup_instal.aspx)
The only problem with this route is the scripting language is in pascal.
Just a question, is the company you work for supplying the boxes because if you are then couldn't you pre-install the software? At least that way there is one less thing that can go wrong.
WIX is a fairly flexible way to create the installer (although the learning curve can be quite a bit as the documentation still is lacking). That would probably be your best bet for installing the components that are actually your product's artifacts. Have it check that the required components are installed, but I wouldn't try to launch installers off of it. Instead, like Seth mentioned, write a Powershell script/VBScript (or Console application) that will do the component checking and launch the old installers for user in the order necessary. Of course you would need a way to capture when the installer finishes before continuing on (don't know if VBScript really has that capability, so Powershell/Console app may be a wise choice). And the final installer called would be your product. This way if there's reboots required the installer can be ran the exact same way and would just keep checking for required components and firing off installers as needed.