|
Thanks for your reply … it got me thinking.
On my home (development) PC I had the same problem if I logged in to my Family account rather than my Admin account. Even though the application (and Access) were installed for both accounts, the error occurred. Strange ... but I could at least duplicate the problem again here at home.
So I tried launching the application again from the Family account. This time when the error message appeared, I just plugged in the flash drive containing the .MSI file and pointed the dialog to it. The application then proceeded to launch normally. As a further test, I then unplugged the flash drive, logged out, and logged back in. This time I was able to launch the application without getting the error message at all. So apparently something was “fixed” by pointing the dialog at the .MSI file the first time.
I wish I understood why this was necessary. Then maybe I could do something to prevent it in the future. I don't want to waste your time trying to track down the source of such a generic error, but if you have any more quick-and-easy insight I'd appreciate it.
Meanwhile, at least I know the work-around. Thanks again for your help!
|
|
|
|
|
It's probably because when you built your MSI, the/a Feature containing your application, or some part of it, is flagged as "Install on first use".
|
|
|
|
|
I am looking for a .net developer to fix and update an existing application. let me know if anyone is interested.
|
|
|
|
|
Then you've come to the wrong site.
Try Freelancer.com.
Be warned, you get what you pay for.
modified 12-Oct-16 22:52pm.
|
|
|
|
|
Reported as spam.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I have designed a Component that has a property which is a list of a different Component, which I need to be able to populate at design time or runtime. I have the property designer popping up a collection editor fine when I want to add the children to the parent. The problem I am having is that the children are being added to the Form's ComponentCollection, rather than the parent Component's ComponentCollection.
I figure I am missing something pretty basic here, but how do I get the children added to the parent's ComponentCollection rather than the form's? I've just spent the last 6 hours searching google and MSDN, to no avail.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
I have my answer (over 24 hours of searching and reading about Designers, TypeConverters, Editors, etc), and it turns out it was right here on CP[^]. Need need a custom CollectionEditor that knows how to deal with components. This article has it all for me - so now at least I can continue.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
This one's a bit hard to explain. If I have an IDisposable object A, and assign one of its (IDisposable) members to a property in object B, will the garbage collector dispose of Object A when it goes out of scope, yet object B does not. e.g.
class ObjectA {
public Image ImageA;
}
class ObjectB : IDisposable {
public Image ImageB;
otherDisposableStuff;
public ObjectB() {
}
void Dispose() {
ImageB.Dispose();
otherDisposableStuff.Dispose();
}
}
ObjectA objA = new ObjectA();
SomeMethod() {
ObjectB objB = new ObjectB();
objA.ImageA = objB.ImageB;
}
What I want to know is will the garbage collector dispose of either objB or its otherDisposableStuff while objA remains in scope? (Note I do not manually dispose of objB)
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
Your example will result in some problems, and has some structural issues.
First, if Image is disposable, then any class that uses it should either be disposable as well or implement a finalization strategy for Image, i.e. ObjectA needs to handle the ImageA memory usage in some way.
Second, without a finalizer on ObjectB (namely ~ObjectB(){Dispose();}) or an explicit call to objB.Dispose(); you never properly dispose of objB and any unmanaged resources handled by it are not released. Simply falling out of scope will not clear these things for you, and it would be a memory leak.
In this instance, you would want to perform a deep copy of ImageB rather than a reference assignment (a copy constructor would make life easy), as if objB were properly disposed, ImageB would be disposed and ImageA is a reference assignment to ImageB. This means that any expected functionality is now kaput, and ImageA were designed correctly it would attempt to disposed of an already disposed object, also a bad thing.
Please take a look at:
Dispose Pattern[^]
Implementing a Dispose Method[^]
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Thanks heaps for that Nathan. I get what you're saying there, and will consequently modify the source of the article I just submitted to take that into account (if only you'd got to me 2 hours ago). I had already read the first article you referenced, but not the second. Thanks to the brain damage I have suffered, however, it takes a lot for the full implications technical article to get embedded into my psyche.
I'll fix it!
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
Well, I'm glad that my first act on a Monday morning was helpful. That's not a given until after the first pot of coffee.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I have just spent the last 2 days using language I thought I had forgotten - all in reference to Microsoft's decision to declare all their ControlDesigners as Internal. All I am trying to do is inherit some controls from standard controls, and use a ControlDesigner to make their size fixed in one direction or the other. Most will be fixed height or fixed width panels but there are a couple of other controls I'd like to play with in this way also. Overriding the SetCoreBounds method, and the Width, Height, and Size properties to make them all operationally ok has been simple enough, and I have that all working. I just personally think that if a control has a fixed height or width, then it shouldn't show the corresponding sizing handles.
I have created basic ControlDesigners that do this perfectly, all following the pattern below:
class FixedHeightControlDesigner : ControlDesigner {
FixedHeightControlDesigner() {
AutoResizeHandles = true;
}
public override SelectionRules SelectionRules {
get {
return SelectionRules.LeftSizeable | SelectionRules.RightSizeable | SelectionRules.Moveable;
}
}
}
I have also created designers with this pattern that inherit from ParentControlDesigner and ScrollableControlDesigner for controls that require those sorts of properties.
The problem is, when I apply this designer to an Inherited control, that control's normal designer is replaced. This means that I don't get the nice little dotted lines around a Panel, or the popup property editors on controls like the ListView or TabControl.
Life would be so much simpler if I could inherit directly from classes like the PanelDesigner, ListViewDesigner, or TabControlDesigner directly, and just add my little SelectionRules override to that. But I can't.
At the moment, the only solution I can see is to copy the source for these Designers, rename them, and pop my snippet in there (not the way the concept of code re-use was envisioned, I'm sure). If anyone can think of a better way, I'd be wrapped.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
You're covering a wide spectrum: Windows Forms controls / designers; web controls; obsolete(d) designers...
You should pick one designer to try and "solve"; everybody's attention is too scattered otherwise.
|
|
|
|
|
I've put this question in the .NET folder since I guess this question is more related to the .NET framework than to C# or C++/CLI.
I'm currently struggling to find a way to load and unload a WPF assembly from an arbitrary path (not a sub directory of the base path) from a C# console application.
I was exploring codeproject for a couple of days (as I have done with some other forums), but I can't actually find a way how to get the console application loading the WPF assembly and instantiating an object from the assembly.
Starting point is the following example as C# console application:
using WPFLibrary;
namespace Caller
{
class Program
{
[STAThread]
static void Main(string[] args)
{
SampleWindow wnd = new SampleWindow();
wnd.ShowDialog();
}
}
}
and the following code as WPF assembly:
namespace WPFLibrary
{
public partial class SampleWindow : Window
{
public SampleWindow()
{
InitializeComponent();
}
}
}
I found various similar questions and suggestions to use:
- Reflection via: Assembly.Load();
- Using Activator.CreateInstance();
- Using a different AppDomain with CreateInstanceAndUnwrap
- Using AssemblyResolve for the AppDomain etc.
- etc
But I could never get my simple example above working if the WPFLibrary is not in a sub directory of the base path of the Caller console application. Since I'm new in this field I may just have missed a simple thing or this scenario may be completely impossible.... Any help would be appreciated.
Background of this question:
In case you are not interested to understand my motivation for this question just skip the remaining of this post. We are developing an c++ dll application for a commercial CAD system. The interface for this system is c/c++ only so there no way to change the complete code to a C# application. This application includes a simple scripting language which also allows to define and execute a graphical user interface. Currently this is encoded in a win32 / MFC way, but since it includes a self build layout manager it is obviously a good idea to think about other alternatives. A perfect match seems to be use use WPF, but that requires to use .NET and to allow XAML definitions a C# library connected by a C++/CLI dll seems to be a good setup.
Some major requirements are:
- The WPF dll must be able to be load from the installation of the application.
- It is required to stop and restart the application (so also the WPF assembly needs to be removed and reloaded).
|
|
|
|
|
|
Thank you for the answer, however this is one of the things which does not work. Assembly.LoadFrom is retrieving the assembly from the one position while instantiating the SampleWindow trys to retrieve it from the Caller path and therefor fails with an exception.
|
|
|
|
|
achimschoen wrote: SampleWindow trys to retrieve it
That makes no sense. SampleWindow doesn't do anything according to your code. It does work.
|
|
|
|
|
Just put my small example to a Visual Studio 2010 compiler and add the follwing code:
static void Main(string[] args)
{
string strPath = @"d:\path";
Assembly.LoadFrom(strPath);
...
Make sure WPFLibrary.dll is not in the base directory but only in d:\path.
|
|
|
|
|
This might help:
COM Callable Wrapper[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
As you can see in the remark section of this command this is only working for sub paths, but not for arbitrary ones.
|
|
|
|
|
If it's simply a matter of "calling WPF in any folder from a console app", then this works:
AppDomain domain = AppDomain.CreateDomain( "newDomain" );
domain.ExecuteAssembly( @"C:\etc\foo.exe" );
Yeah, I know, it's an "exe"; but I don't see where you "need" to instantiate a window only.
In any event, you can communicate across domains.
|
|
|
|
|
I am not sure if the discussion meets the pivotal point of your approach: I think the most problematic part is showing a WPF window from a console application (or later an MFC application). I haven't yet had to do something like that, so I cannot provide details on how to accomplish that.
|
|
|
|
|
The problem you have here is that you aren't actually calling any of the WPF build up behaviour that you would normally see from App.xaml. There's a lot of infrastructure inside WPF that just doesn't exist in the Console world (for instance, how would you expect the Console app to load application resources in a ResourceDictionary), so attempting to instantiate your application like this just isn't going to work. What you would probably have to do is run up the application with an invisible main window, and then call methods inside that instance to fire up the relevant windows that you need.
This space for rent
|
|
|
|
|
The same example I have posted in my initial post does work. It just retrieves the WPF assembly from the same location as the caller application.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
