|
Hi,
I've developed a thin client for a project I'm working on, that gets presented with a load of assemblies to load when it connects to the hub (a web server on the network which exposes a few webservices). It then proceeds to load these assemblies using the System.Reflection.Assembly.LoadFrom(<url>) static method.
When it downloads the modules from the server I'd like to be able to display a status message to the user and update a progress bar as to the download size and progress.
This is purely from a support issue side of things, because the application either loads it from the GAC or from the server depending on the version. If a client stop working suddenly it would be nice for the user to be able to tell me when it updated the assembly.
Does anyone have any ideas?
--
Richard
|
|
|
|
|
>>
Richard Smith wrote:
It then proceeds to load these assemblies using the System.Reflection.Assembly.LoadFrom() static method.
<<
I'm not sure about the actual question you ask - but this isn't the preferred method for handling that scenario. I beleive the preferred method for doing this is to use a .config file for your thin client app that uses the <assemblybinding> tag to redirect the assembly loader to a URL when it looks for certain assemblies (as long as those assemblies have strong names). This will allow you to link directly to your assemblies that are to be deployed on the server, instead of having to use reflection.
So if your thin client linked to MyServerSideAssembly.dll, version=1.0.0.0, culture = neutral, public key token = 012345 , you would have a 'yourthinclient.config' file that contained something along the lines of:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MyServerSideAssembly"
publicKeyToken="012345"
culture="neutral" />
<codeBase version="1.0.0.0"
href="http://your.server.com/MyServerSideAssembly.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
You would then deploy MyServerSideAssembly.dll to a the 'your.server.com' web server.
The assembly loader will take care of downloading the assembly, caching it, and proceeding from there when the thin client tries to reference a type defined in 'MyServerSideAssembly.dll'.
Take a look at the '.Configuration file schema' in MSDN help to get a good idea of all the nifty things you can do with .config files.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
Hmmm interesting... However it doesn't apply since the runtime will only look for one version:
After determining which assembly version to use, the runtime applies the codebase setting from the file that determines the version.
MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfcodebase.asp
I need to be able to update the assembly and not have to worry about updating the client config files. When there's lots of them it gets a pain.
Plus what's downloaded is directly linked to what permissions they have been assigned and what group their in.
Plus I want to play 
--
Richard
|
|
|
|
|
|
I've been developing with MFC for a fair old while now, and I'm looking into c# - but I have a couple of absolute beginners questions before a think about my "beginners project":
1. Does c# / .net have anything like the doc/view architecture? (And if so, what's it called?)
2. Can anyone recommend any good books on moving from MFC to c#? I have a couple of c# text's, but I was hoping for something that might be able to help MFC coders with the migration to c#. Or would people say that this insn't required?
Dylan Kenneally
London, UK
|
|
|
|
|
It is my experience that C# is very primitive compared to MFC. However people are working to rectify the C# GUI shortcomings.
http://www.sellsbrothers.com/tools/genghis/[^]
Michael
"I've died for a living in the movies and tv.
But the hardest thing I'll ever do is watch my leading ladies,
Kiss some other guy while I'm bandaging my knee."
-- The Unknown Stuntman
|
|
|
|
|
Michael P Butler wrote:
It is my experience that C# is very primitive compared to MFC.
Would that be a recommendation for VC++.NET?
I'm still debating which one to learn - well, actually I want to learn both, but I want to start with whichever one is more in demand to try and make my skills as desirable to employers as possible, as soon as possible.
Dylan Kenneally
London, UK
|
|
|
|
|
I doubt there will be a "more in demand" between MC++ (get used to calling it that) and C#, to be honest. Both suit different needs and both needs will have a market.
MC++ will certainly be easier for you to learn, but then C# is hardly rocket-science either.
Incidentally, if you're looking for Document/View architechtures in C#, you're looking in the wrong place 
Paul
Life is just a sexually transmitted desease - Matthew Wright (ex-journalist, TV presenter) 10-Oct-02
I finally have a sig! - Paul Riley (part-time deity) 10-Oct-02
|
|
|
|
|
Dylan Kenneally wrote:
Would that be a recommendation for VC++.NET?
It depends on what you want to write. Personally I find the disadvantages in the C# GUI outweigh the .NET framework advantages.
I'm sticking with MFC for writing desktop applications and not using any of the .NET framework.
I'm still learning C# but it won't be usedto write any real world code that requires a lot of UI. I'll wait for the next release for that.
Michael
"I've died for a living in the movies and tv.
But the hardest thing I'll ever do is watch my leading ladies,
Kiss some other guy while I'm bandaging my knee."
-- The Unknown Stuntman
|
|
|
|
|
.NET for me is only for self-training at home. C++ is brute force.
Think redistribution : to launch your .NET app, users have to download between 20MB and 180MB of MS run-times. In addition, you don't control the redistribution, unlike the MFC dlls, which means users may update the .NET run-time without telling you, and may not be able to run your app any longer then (more than 100 behaviour updates between .NET 1.0 and .NET 1.1, almost none are backward compatible).
She's so dirty, she threw a boomerang and it wouldn't even come back.
|
|
|
|
|
__Stephane Rodriguez__ wrote:
In addition, you don't control the redistribution, unlike the MFC dlls
Very interesting point. So we have to trust MS about compatibility ?
Some of those that work forces
Are the same that burn crosses !
Killing In The Name/Rage Against The Machine
|
|
|
|
|
Until .NET has more playground, apps developed by you will generally speaking not work on an end user machine, because of a wrong .NET run-time (huge redistribuables by the way, think about those connecting the net with dialup).
KaЯl wrote:
So we have to trust MS about compatibility ?
It's obvious that the business model of MS is to promote a .NET certification. In other words, MS is more and more expecting us to go through their sort of exam before our app is said to be "compliant", or ".NET proofed" or whatever.
This is not really new stuff. We know for years there was the windows logo program, even if in practice almost no MS-partner company in the world can achieve it.
We are just at the premisses of that, but you've got the idea. You can figure it out by downloading FxCop (gotdotnet.com).
It's about figuring out why MS started all that hype around security last year. They wanted to tell everyone (make everyone blindly think), that new tools are more prone to enforce reliable security. They have said if users want more security, they'll have to go definitely the .NET way, which means upgrading their OSes. In turn, developers are going to be asked to develop only .NET apps (because MS claims this is better for security) which is not only a loss of freedom, but although a way to constraint developers to BUY all possible .NET related stuff, download, install, test, etc.
Which means this is the end of low-budget software development.
"On ne prête qu'aux riches...".
How low can you go ?
(MS retrofuck)
|
|
|
|
|
Thx for this detailled answer 
Influence of the Evil, Influence of the Good, which of both will go further?
Wobbly destinies, dubious dreams, which of both is good for nothing?
L'emprise du Mal, l'emprise du Bien, lequel des deux ira l'plus loin?
Destins bancals, rêves incertains, lequel des deux est bon à rien?
Come On Boys/Ludwig Von 88
|
|
|
|
|
__Stephane Rodriguez__ wrote:
Think redistribution
This statement is only correct if you are writing an app to be distributed to end-users online. If you are shipping by CD, or if you are mainly supplying software to corporations, or are an IT division developing in-house software, this is not a concern. And I think those areas are the ones that MS has been targetting for the first wave up .NET users.
It'll be years, I think, before the .NET framework is widely distrubuted enough among the average computer user for it to make sense to develop end-user/consumer software with .NET. It's big impact in the next few years (if it has one) will be on the server side and in corporate backends.
[Edit]
--> In regards to framework versions and such (sorry, I hit the submit button instead of the reply button  )
[/Edit]
DotNet 1.1 can be installed on the same computer as DotNet 1.0. An app written for 1.0 will run with the 1.0 framework, and an app written for 1.1 will run under the 1.1 framework.
If only the 1.1 framework is installed, the 1.0 app will try to run under the 1.1 framework. And most likely it will fail miserably, because of the imcompatibilities you point out. However, I don't see how this is any different than other upgrade scenarios, unless upgrades are never anything more than bugfixes that don't change interfaces.
If only the 1.0 framework is installed, the 1.0 app will run fine, and the 1.1 app will refuse to run.
The big problem I see with going from 1.0 to 1.1 is not getting built applications to run, it's rewriting your 1.0 apps when it turns out they are using behavior that has been altered in 1.1. This scenario worries me, of course. Our shop isn't looking at using 1.1 in the next year, as far as I know.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
Russell Morris wrote:
If only the 1.0 framework is installed, the 1.0 app will run fine, and the 1.1 app will refuse to run.
You can get a 1.1 app to run on a 1.0 only machine by creating a .config file for the application and have the runtime redirect assembly bindings.
TSWizard_v1.1.zip (28.8 Kb) here is an assembly and a demo application, compiled under .NET 1.1 (you can verify this by running ildasm on the files and seeing that it binds to version 1.0.5500 of the BCL). In the .config file are the appropriate items needed to make it run under v1.0 of the framework.
You can create this .config file by hand *or* take the easy (and less error prone) way out and let the ".NET Framework Configuration" utility do all the work.
James
Sig code stolen from David Wulff
|
|
|
|
|
You can't really say this technical thing to an end-user, can you ?
That's exactly what happens in practice. You double-click on the app, and it fails with a stupid messagebox. No way to fix it.
Now if your words are for developers, you simply expect them to have BOTH run-times installed, tested, and upgrading problems fixed before starting the distribution. This is not exactly what you read in MS marketing brochures when they claim great productivity gains...
That's not exactly what I thought about next gen dev platform. I thought the existing CLR would try to figure out what was missing, start a wizard, and download missing stuff. Automatically, no need of any additional line of code here, since at compile-time you have already told the compiler which versions of assemblies to compile and link against.
In addition, the fact that new regular (one per quarter) .NET run-time comes with new features makes you, the developer, feel like using them. But, and here is the trouble, you cannot really expect the end user to have the same run-time than you, otherwise it requires not only the end user to more or less be an MSDN addict and start downloading all possible updates whenever possible, but the user may be asked to do it without any visible value for it. When you see the sizes of redistribuables (main, and additional), that's really an issue.
Final point, since the .NET run-time is often updated (MS site promotes always the latest, and removes access to older stuff, an amazing habit you don't mention) it's not a point to have the .NET run-time available by default on coming OSes.
How low can you go ?
(MS retrofuck)
|
|
|
|
|
now , i'm thinking about developing a simple anti-virus program as a graduation project.So anyone know where to find articles that would help me .. about Virtual computers for example.
all i know about virtual computer is that i isolate a part of the memory & create a virtual computer & test the file on it .. if it destroyed the computer ,then it's a virus.
aslo what i should read about or know to such idea ?
thanks
plextoR
plextoR
|
|
|
|
|
hmm, I think you want to write an emulator.
however, this is pretty complex - also most serious viruses use self modify code and encrypted payloads....
I would suggest reading books on how to write a virus first, then think about how to catch them
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
He could use something like VMWare. I use it all the time to test installations and to keep fresh demos of software I have developed (so it does not get corrupted by other software). Of course, in order to run a virtual computer, you have to set aside enough RAM to run the computer, and startup takes a while.
Just curious...why write a virus checker like this? Many viruses don't go off until a certain date, so they would not affect the virtual machine in any way until the correct date. Others only corrupt machines randomly. Still others don't corrupt the machine, but use the machine as a launching point in order to spread. With a virtual machine, you would have just let this virus onto your network.
This reminds of of Turing Machine theory and complexity theory. It is provable that no program running in finite time can determine if another, arbitrary program will stop executing. In other words, it is awfully difficult to construct an algorithm that can detect a virus automatically.
|
|
|
|
|
agreed, thats why i thought a pattern recogniser would be more sensible - virus would tend to use the same code snippets that would be unlikly to be found in a standard program.
on could use some baysian hack that could work out if the code 'looked' dubious.
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
Does anybody know if it is possible to obtain the source code of the Microsoft TreeView control?
If this is not possible, is it possible to find or purchase the source code of a third party TreeView control?
|
|
|
|
|
Anakrino || Salamander || SSCLI.
Beware : .NET Treeview constructor marked internal.
She's so dirty, she threw a boomerang and it wouldn't even come back.
|
|
|
|
|
__Stephane Rodriguez__ wrote:
SSCLI
The Windows Forms Namepsace isn't implemented in the SSCLI/Rotor.
Norm Almond: I seen some GUI's in my life but WTF is this mess 
Leppie: I made an app for my sister and she wouldnt use it till it was colorful enough
Norm:good point leppie, from that statement I can only deduce that this GUI must be aimed at children
Leppie:My sister is 25
-Norm on the MailMagic GUI
|
|
|
|
|
I agree. But you get the idea.
She's so dirty, she threw a boomerang and it wouldn't even come back.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
