.NET (Core and Framework)

subject : programming with .NET Framework to browsing my bank account, buy and sell stock shares

1-Feb-05 20:27

NET dependencies imply NET framework must be installed. The NET framework install automatically checks for the Windows Installer (and upgrades depending on the version found).

So the assumption is that when your project is dependent on NET you no longer need the InstMSI's, because of one of two reasons:

1) The NET framework is already installed so the Windows Installer service was installed/updated and does not need to be bootstrapped.

2) The NET framework will have to be installed, in which case the NET framework will take care of bootstrapping Windows Installer.

So including InstMSI in any setup that installs NET assemblies is pointless.

But there is a problem: Now instead of needing to bootstrap the Windows Installer (i.e. include InstMSI) you need to bootstrap the NET framework, because it might not exist on the target machine.

But unfortunately you cannot just add the NET framework install to your setup like you did with InstMSI.

See the MSDN for what is now required to deploy apps with NET dependencies:

http://support.microsoft.com/default.aspx?scid=kb;en-us;324733[^]

Robert

Close Network1-Feb-05 5:47

Close Network

1-Feb-05 5:47

Has anyone ever tried to code a piece of software to browse his bank(hsbc for instance) accounts, buy sell stock shares thru this software. This software is not meant to be only with ASP.NET, it can also be built using MFC or any other related libraries of .NET framework or previous Microsoft related libraries. I have got a similar piece of code in Java, however I would like to study its .NET version, what would it be like and what libraries of framework would be used, what methods be called to make a connection to the bank's server, browse accounts and buy and sell stock shares. I am trying to code a non-asp version of it for http://www.hsbc.com.tr/. Does anyone have any idea. I would later automatize my buying and selling thru some technical indicators..

Thank you for any opinions..

born to ask

Remoting channels

neeru26197631-Jan-05 22:33

neeru261976

31-Jan-05 22:33

I am using .Net remoting in windows 2003.
Remoting channel i am using is "pipe".
Now the problem is i am not able to get the proxy object for the remote object.

my config files are:
for client:
------------
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type="CECAdapter, ArECA" url="pipe://MyPipe/ecadapter.rem">

<client>
<wellknown type="ConfigMgr, ArConfigMgr" url="pipe://MyPipe/ConfigMgr.rem">

<client>
<wellknown type="DCEventManager, ArSysEventMgmt" url="pipe://MyPipe/DCEventManager.rem">

<client>
<wellknown type="RegnServer, ArRegnServer" url="pipe://MyPipe/RegnServer.rem">

<channels>
<channel type="Remoting.Pipe.PipeChannel,Remoting.Pipe,Version=1.0.1.0, Culture=neutral,PublicKeyToken=151990e70f5d092b" pipe="Auto">

for server:
------------
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton" type="CECAdapter, ArECA" objecturi="ecadapter.rem">

<service>
<wellknown mode="Singleton" type="ConfigMgr, ArConfigMgr" objecturi="ConfigMgr.rem">

<service>
<wellknown mode="Singleton" type="DCEventManager, ArSysEventMgmt" objecturi="DCEventManager.rem">

<service>
<wellknown mode="Singleton" type="RegnServer, ArRegnServer" objecturi="RegnServer.rem">

<channels>
<channel type="Remoting.Pipe.PipeChannel,Remoting.Pipe,Version=1.0.1.0, Culture=neutral,PublicKeyToken=151990e70f5d092b" pipe="MyPipe">

Can any body help me to resolve the issue.

Re: Remoting channels

Charlie Williams1-Feb-05 4:51

Charlie Williams

1-Feb-05 4:51

You should select "Do not treat <'s as HTML tags" or encode the brackets with & l t ; and & g t ; (no spaces)

Charlie

<font color="blue">if</font>(!curlies){ <font color="blue">return</font>; }

Installer woes

Arun Bhalla31-Jan-05 19:29

31-Jan-05 19:29

I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1.

My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems.

1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch, fearing general corruption in the file. This seemed to help (especially the latter), but not for too long, and it's not a sustainable solution, even if it's not a placebo. In addition, which may or may not be related, the Setup.MSI doesn't seem to always uninstall all registry entries, and because of that, I've had to add a few lines to my Uninstall custom action. It doesn't seem right to me that the MSI would sometimes not uninstall registry entries that it added in the first place.

2) The second subproblem is more specific to my project, and this occurs sometimes when I'm registering the main assembly. The main assembly is registered in the overridden OnCommitted() method of the Installer class, presumably after the previous version's main assembly was unregistered in the OnBeforeUninstall() method. In the case where the previous version and the new version were installed in the same "Program Files" folder, the assembly containing the Installer class will have the same exact CodeBase, but they'll of course have a different FullName because the assembly version has been automatically incremented. It seems that sometimes the Commit custom action will re-register the old assembly instead of registering the new assembly. My registration code looks like this:

RegistrationServices rs = new RegistrationServices();
rs.RegisterAssembly(MyAssembly, AssemblyRegistrationFlags.SetCodeBase);

and my unregistration code looks like this:

RegistrationServices rs = new RegistrationServices();
rs.UnregisterAssembly(MyAssembly);

MyAssembly is defined as a property:

Assembly MyAssembly
{
	get
	{
		return Assembly.LoadFile(InstallDirectory + "assembly.dll");
	}
}

I used to use Assembly.Load(path) instead, but it seemed that Assembly.LoadFile(path) worked better. My concern is that either the Uninstall and Commit custom actions share an AppDomain, so sometimes MyAssembly might return the previous assembly during the Commit phase if the previous assembly wasn't somehow still in Commit's AppDomain after Uninstall finished. I tried creating a temporary AppDomain and then loading the assemblies within that, but it threw a deserialization exception. I suppose the overall issue of this subproblem is that I'm trying to register and unregister assemblies without knowing the FullName of either assembly, as I'm trying to semi-automate the build process and stay within VS.NET as much as possible (for now).

I know these are complex and possibly peculiar problems! While I'd love for someone to post a solution for either (or both!) subproblems, at the very least, I'd appreciate hearing tips regarding debugging deployment projects and custom installation classes, similar stories of installer woes and solutions, and recommendations for possibly better installation/deployment tools than VS.NET's deployment projects. Something like InstallShield seems like overkill, but maybe it's what I need to have dependable installations.

Thanks for reading this far!
Arun

rwestgraham1-Feb-05 15:27

1-Feb-05 15:27

This is not much help. I've had problems with running custom actions on uninstall as well and I have not yet resolved them.

One thing you can do to at least try to get some more information is to create a full log file of the installer actions.

Run your msi package from the command line using the following verbose logging command line options and it will generate a complete log. Unfortunately, interpreting the log is another matter, and acting upon that interpretation still another ... Frown | :-(

But it is a starting point at least.

Typical command line is:

msiexec.exe /L*v "C:\MySetup.log" /I "C:\MySetup.msi"

i.e.

msiexec.exe /L*v <fully qualified path/filename for the log to create> /I <fully qualified path to the msi you want to run in verboise logging mode>

Good Luck!

Robert

Arun Bhalla2-Feb-05 8:46

2-Feb-05 8:46

Thanks for your reply! I have been looking at the full log file off and on for several months, and I don't see anything in there explaining my problems, especially why the Uninstall custom action sometimes doesn't run.

Arun Bhalla2-Feb-05 9:27

2-Feb-05 9:27

Do you think our deployment projects have anything in common besides the obvious (.NET, etc.)? Is there some way we could work together on solving this?

rwestgraham2-Feb-05 11:57

2-Feb-05 11:57

Actually mine was very simple.

I'm sure you've seen the MSDN walkthroughs on how to create a custom action to compile NET assemblies into Native Images on the target machine. Well when that happens it adds an entry for each native image into a system table (you can view the list with ngen /L command I think.)

All I was trying to accomplish was creating a "well behaved setup" that would remove any Native Image entries it created using the Uninstall event.

It was a while back and I don't really remember much. I do remember that it should have been simple, but I never got it to work, and got tired of messing with it. Smile | :)

I came to the conclusion that the Installer class worked fine for Install actions, but because I had problems getting even a simple uninstall action to run, I pretty much decided to abandon using them.

I think that until I can afford to get InstallShield, I'll go with creating a C++ dll to run any sort custom actions and just manually edit the Action tables in the msi to make sure my uninstall action calls in a DLL are made during an uninstall before the dll itself is removed.

There are some other things I don't like about the msi packages created with the NET IDE anyway, so I've devoted more time to learning about manually creating entire installs using Orca rather than digging any further into the Installer class.

Sorry ...

Robert

Arun Bhalla2-Feb-05 13:13

2-Feb-05 13:13

Ah, okay. Well, I think most of my critical woes are gone now. I was trying to register assemblies in a custom action, and that was a bad idea, so I let the MSI handle the registration. I still notice that the MSI doesn't seem to delete some registry entries that it added, and perhaps sometimes the Uninstall custom action isn't called, but that's more of a matter of tidying up the registry than something critical.

(I try to clean up the Registry after myself, but it's not my fault if the MSI sometimes can't be bothered to do it.)

Thanks!
Arun

rwestgraham2-Feb-05 13:29

2-Feb-05 13:29

Yes. I try for clean uninstalls, but at some point sometimes you have to just let it go.

I've never seen a Microsoft product itself that said it was logo certified????

And some of their setups are pretty bad.

When they released the eval versions of SQL Server 2000, I got one and put it on my machine. It ruined my MSDE server, and I had to go in and do massive manual registry cleanups to get MSDE installed back on my machine and working properly.

Now I do registry backups before I install anything from Microsoft, LOL.

Robert

Arun Bhalla2-Feb-05 13:37