I have used Click-Once and it appears so far to work very well. I have been frustated though by the lack of control of the installation folder but I'm not sure if thats just down to me not reading enough so far :)
I didn't carry netrun forward because I think ClickOnce is a generally better solution. NetRun should still work under .NET 2.0 though - it isn't a very complex bit of code, and the href exe deployment concept continues to work in .NET 2.0 just like it did in .NET 1.0.
Odds are that you can simply recompile NetRun under VS 2005 and it will work (though I haven't tried that myself).
We are using NetRun and the CSLA. Since the conversion of our code to C# 2005 and .NET 2.0 we have noticed that NetRun does not work as expected. We have been using NetRun for deployment for the last year or more, with no problems.
Now when we deploy a new version of the code to the web server, we have noticed that NetRun does not get the latest version of the deployed code. The previous version of our exectubable is being used and the loading of the application fails because all the dependent assemblies cannot be resolved.
I have found some documentation around the fact that Assembly.LoadFrom no longer works as expected in .NET 2.0...here is the link:
http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/fusion.aspx
Has anyone else had this problem? and if so is there a reasonable work-around? If not, it looks like we will be using the Updater Block since Click-Once is too inflexible.
Marty
From: mcerisano [mailto:cslanet@lhotka.net]
Sent: Wednesday, August 30, 2006 12:18 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] NETRUN?We are using NetRun and the CSLA. Since the conversion of our code to C# 2005 and .NET 2.0 we have noticed that NetRun does not work as expected. We have been using NetRun for deployment for the last year or more, with no problems.
Now when we deploy a new version of the code to the web server, we have noticed that NetRun does not get the latest version of the deployed code. The previous version of our exectubable is being used and the loading of the application fails because all the dependent assemblies cannot be resolved.
I have found some documentation around the fact that Assembly.LoadFrom no longer works as expected in .NET 2.0...here is the link:
http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/fusion.aspx
Has anyone else had this problem? and if so is there a reasonable work-around? If not, it looks like we will be using the Updater Block since Click-Once is too inflexible.
Marty
Thanks for the feedback.
We have been using NetRun and the Assembly.LoadFrom for many months with no issues. So I can vouch for the fact that this mechanism has worked pre-2.0. Post-2.0 is another story.
Its troublesome that the Assembly.LoadFrom call now does not retrieve the latest version from the server. The only way to get the lastest version is to clear the temporary internet files. This is not a valid deployment requirement for our users.
It would be great to know if anyone using .NET 2.0 has verified that NetRun (Assembly.LoadFrom) actually works...
Skeeboe:
Per the Click-Once FAQ Site:
http://www.windowsforms.net/FAQs/default.aspx?PageID=1&CategoryID=24&tabindex=2
Q. I want my application to be installed to a specific hard drive location, how can I achieve this?
A. The install location of “ClickOnce” application cannot be managed by the application. This is an important part of making “ClickOnce” applications safe, reversible, and easy to administer. Note, the administrator can specify where the “ClickOnce” store should reside.
I have 10+ HUGE programs that are all interconnected. They all can launch each other and need to know each other's locations. There are more issues than that but that's a big one. It's much easier to work with interconnected programs if they all reside in the same folder.
I'm not even sure if NETRUN can handle our needs, I was going to start testing with it and noticed it wasn't carried over (or even mentioned it looks like) in CSLA 2.0.
an idea for you ....
click-once was designed to isolate app dependancy so that for example 2 or more versions could be installed w/o stomping out each other.
while the path is "hidden" it is still there, I think with a bit of care you can build code to "find" the apps. what about having links to the app's in a known location ?
each app puts a link in say program files\complex app\links\
and each app can build a list of links to other apps to run on the fly...
each time a click-once app is updated it re-writes it's link so all the other apps can find it via the link.
-----Original Message-----
From: Rockford Lhotka [mailto:cslanet@lhotka.net]
Sent: Wednesday, August 30, 2006 1:50 PM
To: Cerisano, Marty (JUS)
Subject: RE: [CSLA .NET] NETRUN?From reading that link though, it sounds like the change only affects you if you are using the GAC. It doesn't indicate that there'd be any effect on purely dynamic loaded assemblies that aren't in the GAC.I can say though, that I have never tested NetRun under 2.0, so it is possible that Microsoft did break href exe. I find that unlikely however, because that would have a higher severity than the relatively obscure issue described by that link. A lot of people use href exe - at least in 1.x - and I've seen other references to the effect that href exe continues to work in 2.0.Rocky
From: mcerisano [mailto:cslanet@lhotka.net]
Sent: Wednesday, August 30, 2006 12:18 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] NETRUN?We are using NetRun and the CSLA. Since the conversion of our code to C# 2005 and .NET 2.0 we have noticed that NetRun does not work as expected. We have been using NetRun for deployment for the last year or more, with no problems.
Now when we deploy a new version of the code to the web server, we have noticed that NetRun does not get the latest version of the deployed code. The previous version of our exectubable is being used and the loading of the application fails because all the dependent assemblies cannot be resolved.
I have found some documentation around the fact that Assembly.LoadFrom no longer works as expected in .NET 2.0...here is the link:
http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/fusion.aspx
Has anyone else had this problem? and if so is there a reasonable work-around? If not, it looks like we will be using the Updater Block since Click-Once is too inflexible.
Marty
From: Cerisano, Marty (JUS) [mailto:cslanet@lhotka.net]
Sent: Thursday, September 07, 2006 12:19 PM
To: rocky@lhotka.net
Subject: RE: [CSLA .NET] NETRUN?I thought you might be interested in this article.It seems that they purposely broke NTB so that we would be forced in the direction of ClickOnce. Seems heavy handed.Marty-----Original Message-----
From: Rockford Lhotka [mailto:cslanet@lhotka.net]
Sent: Wednesday, August 30, 2006 1:50 PM
To: Cerisano, Marty (JUS)
Subject: RE: [CSLA .NET] NETRUN?From reading that link though, it sounds like the change only affects you if you are using the GAC. It doesn't indicate that there'd be any effect on purely dynamic loaded assemblies that aren't in the GAC.I can say though, that I have never tested NetRun under 2.0, so it is possible that Microsoft did break href exe. I find that unlikely however, because that would have a higher severity than the relatively obscure issue described by that link. A lot of people use href exe - at least in 1.x - and I've seen other references to the effect that href exe continues to work in 2.0.Rocky
From: mcerisano [mailto:cslanet@lhotka.net]
Sent: Wednesday, August 30, 2006 12:18 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] NETRUN?We are using NetRun and the CSLA. Since the conversion of our code to C# 2005 and .NET 2.0 we have noticed that NetRun does not work as expected. We have been using NetRun for deployment for the last year or more, with no problems.
Now when we deploy a new version of the code to the web server, we have noticed that NetRun does not get the latest version of the deployed code. The previous version of our exectubable is being used and the loading of the application fails because all the dependent assemblies cannot be resolved.
I have found some documentation around the fact that Assembly.LoadFrom no longer works as expected in .NET 2.0...here is the link:
http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/fusion.aspx
Has anyone else had this problem? and if so is there a reasonable work-around? If not, it looks like we will be using the Updater Block since Click-Once is too inflexible.
Marty
Copyright (c) Marimer LLC