You might want to look into an option where the framework elements you need are compiled into your application. These are generally fairly expensive though, but they might be just what you want. Take a look at things like Thinstall[^] or Xenocode[^].
Deja View - the feeling that you've seen this post before.
Just wanted to come back and thank everyone for the help. I believe we're going to be going with a Xenocode solution. I'm trying to compare their Virtual Application Suite and their PostBuild products right now but I have a feeling I'll be going with VAS. It has the snapshotting capability (take a snapshot of your system before and after and the delta is what needs to be virtualized). But the obfuscation of PostBuild is tempting.
Anyway.... thanks to everyone for all the help and pointing me in the right direction!
I generally agree with what other people have being saying here. I doubt this is actually achievable with .net, and the best thing is to somehow get it agreed that .net is already on the PC. Second to that would be to use one of the various app virtualisation packages, but they don't come cheap.
One thing that might be worth trying though is the .net client profile[^]. It's a cut down version of the framework that only includes the basics and the winforms/wpf/client stuff and not any of the asp.net/web stuff. I've never used it so I can't comment on it's install speed, but it's cut down so it may be faster.
Well, it's a record keeping app so the owner would probably run it several times but it might be used only one time in an emergency location and that's when it has to run fast and that's also when the host machine probably isn't going to allow anything else to be installed. I know I'm being vague but I have to be careful with the NDA I signed.
It looks like VMWare's Thinstall does exactly what we need it to but the price is sooooo high. Anyone know of something out there that does the same thing but for less money? I know... but a girl can dream, can't she?
I don't know if this is possible, but what about the U3 enabled USB Sticks. Programs can be run directly from them. Is there one with sufficient capacity to hold your app and an installation of the framework?
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
I'm working with a .NET System.Windows.Forms.TreeView (both .NET 2.0 and 3.5) and have a problem with the check boxes not correctly affecting/reflecting the TreeNode's Checked state.
I've enabled checkboxes and have event handlers for BeforeCheck and AfterCheck to act whenever a TreeNode's checkbox is checked or unchecked. My problem is that if you place the mouse pointer directly on a node's checkbox and double-click, the checkbox's visible checked state toggles, but the Checked state of the corresponding TreeNode does not actually change. Further the TreeView's BeforeCheck and AfterCheck handlers are never invoked [this actually seems consistent and follows from the observation the these events are raised exactly and only when anything actually changes the TreeNode.Checked property, not the state of the visible check box]. A single(left)-click on the check box works properly: the Before/AfterCheck handlers are invoked and the TreeNode's Checked state changes correctly.
Double-clicking elsewhere on the displayed node toggles the expanded/collapsed state (as I assume it's suposed to do).
I've tried to find a TreeView event handler that will allow me to catch a double-click directly on the checkbox and either ignore it or modify the node's checked state myself. But I've been unable to find an event handle to catch this.
Is this a known bug? Could there be something I'm doing wrong? It gives my application a rather annoying incorrect behavior and I really don't want to abandon the use of TreeView and have to reimplement a correct "TreeView"!
Can anyone steer me toward any information about this behavior of TreeView?
If this is the wrong category for my problem, please direct me to the correct place to post my question.
Recently, I have been unable to build any of my C++ projects in Visual Studio .NET 2003 The error is always of the form:
fatal error C1083: Cannot open source file: '.\hello.cpp': No such file or directory
I received the same error when I created a brand new c++ project (empty project, Win32 Console) of Hello World!
I have found the following information: http://msdn.microsoft.com/en-us/library/et4zwx34%28VS.80%29.aspx but I don't know how to check and correct all the possibilities
- My include environment variable is set to "c:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include"
- It does not make a difference to use the syntax: #include <stdafx.h>
I was previously able to write and compile programs without a problem, is there a setting that has been changed somehow?
Appreciate any ideas/suggestions; thanks for your time.
I want to be able to distribute an excel workbook to customers, but don't want people to have access to the excel workbook's macros and two of it's sheets. We don't trust the password protection provided by excel (you can buy one of many applications on the web that claim to be able to crack it).
What I think we need is to encapsulate the excel file into a .Net application that provides a basic excel viewer (i.e. the application comprises of a title bar and the excel sheet). Our customer will be able to enter data onto the sheet and click a button that calls the macros (that update the sheet).
Is this solution possible? Can anyone think of a better solution?
Unfortunately moving the functionality out of an excel workbook completely is not an option.
My God! What helpful answer - thank you, your the best! (I though I'd join in on your sarcasm
Anyway, unfortunately I'm stuck with the said problem; I need to provide a mechanism to prevent access to the excel file. I was hoping .Net had some sort of GUI component for interacting with Excel files. I have tried searching the web, but haven't had any luck.
For those who have some constructive suggestions, I would be grateful for your help.
I was hoping .Net had some sort of GUI component for interacting with Excel files.
Yes, see that doesn't exist therefore this part of my comment was constructive:
led mike wrote:
I suppose you are left with discovering whatever features they put in Excel
Although I see how my sarcasm might have disguised the helpful aspect of it. Also you have not mentioned knowing about the Microsoft provided Primary Interop Assemblies[^] for Office products. These will allow you to easily access existing Excel features that can help with your requirements.
How about you embed your excel sheet as a Resource into your .Net/C# executable. Then on startup, you extract your embedded resource and create a new spreadsheet on the User harddisk that is an exact representation of you embedded resource - minus all of the password sensitive data. Then you can delete your embedded resource?
I have a project which uses DirectSound. I use C#.NET and VS 2005 under Windows XP(x86). Everything is OK, but when I tried the exe file under Windows Vista(x86), it crashed during initialization. I installed VS 2005 + SP1 + Patch for Vista to debug the project, but since that I have not had any problems with my project. It starts, plays sounds and everything is fine now.
So, my question is: where is the problem under Vista? I can't tell other people to install VS to use my application. There might be a patch or something like that but I can't find such a solution. So, help me to solve this problem, please!
The OS the binaries are built on makes no difference.
The binaries should run fine on Vista unless the OP specifically used
something only supported on XP, in which case (s)he's not doing proper
error/exception handling (which is probably the case anyway, unless it's
just a case of the required .NET framework not being installed )
The OS the binaries are built on makes no difference.
Yeah, I kind of sort of vaguely kind of knew that. Binaries aren't really binaries these days anyway.
We're developing mostly on Vista, but we'll be deploying on XP and Mono (and no doubt Win 7 as well). I tend not to worry about all that sort of strategic stuff though, and just get on with my bit of it.
There are three kinds of people in the world - those who can count and those who can't...