|
I would like to make a windows service that gets started when application is launched and internet connectivity is available then checks for updates. It checks for and notifies user to download new updates.
Now, services can not be interactive. SO how the launching and the making this interactive can be achieved.
Does making services interactive posses security threat and is there any alternative to achieve the same ?
Thanks in advance.
|
|
|
|
|
Yes, they are a threat. There is a reason why you can't make then interactive any more.
Do it the correct way and have the service listen on a named pipe. Then you can have a second application launch when the user logs in and communicates with the service over the pipe. That application can put up any user interface required.
It takes a bit more work, but is infinitely more secure, stable and supportable.
|
|
|
|
|
Abhay B wrote: and notifies user to download new updates
In that case it should be a normal Windows application that runs in the user space. A service runs before the user logs on, when there is no desktop (and no user!) to notify.
A normal app does what you want, and wastes less resources when the user isn't logged in. Next, the service might have trouble if there are multiple users logged on that machine.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
select a.*,b.* from a
left join b on a.type = b.type and a.item = b.item
I want to use linq display all a.columns and b.columns
Column is dynamic!
|
|
|
|
|
Linq doesn't have an equivalent to *. Really, Linq never does a SELECT *. It always executes a query by naming each and every column in the source object. An example of a Left Join would be something like:
from itemA in a
join itemB in b on a.type equals b.type into bt
from itemB in bt.DefaultIfEmpty()
select new {
aObj = itemA,
bObj = itemB
}
In order to generate a new object from a list of unknown columns, you'd have to use so ugly Reflection code to get the columns and build a new object from them. Sorry, I don't have an example as I find the concept of SELECT * ugly and very prone to breaking code in the future, even in Linq.
You may want to read up on How to: Perform Left Outer Joins[^] and note the links in the left-side navigation pane.
|
|
|
|
|
Agreed - SELECT * FROM should be banned for a pile of good reasons!
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
OriginalGriff wrote: SELECT * FROM should be banned
Except in VIEWS
|
|
|
|
|
Even then it should be banned.
What if one of your columns called a user defined function on every row returned?? Say this function resulted in a large load on the server, but was fine for datasets of a couple of dozen records? Now what if this table had millions of records in it?? I really wouldn't want a * query beating the crap out of my server.
|
|
|
|
|
I meant using SELECT * in the definition of the view, not while doing a select on the view.
|
|
|
|
|
I know what you meant. It is NOT supported by Linq.
You would have to use some very ugly Reflection code in a seperate method to build a new object from the supplied objects, then build your collection from there. No, I don't have an example because it's a very bad idea to do what your thinking about.
Just because you can do it in a database engine doesn't mean you can do it in Linq. Linq is not a database engine.
modified 17-Oct-13 9:25am.
|
|
|
|
|
Nope. It should still be banned then. You should always know what's being returned. Relying on SELECT * is just being lazy - how long does it really take to explicitly select columns, especially given the number of code generators that abound.
|
|
|
|
|
I have seen many production systems where views are used to streamline access to tables and avoid direct access to tables. In these cases, a view is just a "wrapper" around a table. Imagine, if the underlying table structure changes (new column added or an existing column removed), then the view becomes invalid and has to be updated with the new structure. Doing a SELECT * in this situation will avoid this issue.
I know it is still bad, but there are already millions of systems that do this. Wherever I am asked to do a database upgrade or performance improvement, I am very cautious about views and don't touch them unless I'm sure of what I am doing.
|
|
|
|
|
Shameel wrote: I know it is still bad, but there are already millions of systems that do this.
That doesn't make it a correct thing to do.
|
|
|
|
|
I find this a really useful resource [^]for linq
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
you don't have to make join if you have maintained primary and foreign key between parent and child tables.
For example
Parent Table : A
Fields : a1 (pk), a2, a3
Child Table : B
Fields : b1 (pk), a1 (fk), b2, b3
Then your linq query would be as mentioned below :
var t = (from a in Enities.A
select
a.a1,
a.a2,
a.a3,
a.B.b1,
a.B.b2,
a.B.b3 )
Regards,
CodeBlack
|
|
|
|
|
His real problem is that he has a unknown lists of properties on the A and B objects. Linq won't project to a new object from fields that you cannot specifically name.
|
|
|
|
|
Have you asked yourself how to paging in the DevExpress GridControl so, I want to code like this:
if (e.Button.ButtonType == NavigatorButtonType.PrevPage)
{
}
if (e.Button.ButtonType == NavigatorButtonType.NextPage)
{
}
Thanks. 
modified 13-Oct-13 22:19pm.
|
|
|
|
|
nhanlaptrinh wrote: Have you asked yourself how to paging in the DevExpress GridControl
No. Never wanted to do it. Why do you ask?
But if you want to, then you could always try looking for a search engine that might help. There must be one...oh! Here is one you might not have heard of: Google[^]
You can ask it questions, and it finds pages that could help, apparently. Why does nobody know about this? It could be useful!
Lets try it shall we: Google: "paging in the DevExpress GridControl"[^]
OH! Look! Over 50,000 pages talking about it!
In future, please try to do at least basic research yourself, and not waste your time or ours.
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
Should we take it that sarcasm is no longer the lowest form of wit? 
Veni, vidi, abiit domum
|
|
|
|
|
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
I have found but there is no content that I need, and what you know to help me, thanks.
|
|
|
|
|
I want to export GridView (25000 records) to Excel. But i got an error message like : System.OutOfMemoryException was Thrown.
But i need to export the records (even more than 25000 records) to excel
How to solve this ?
|
|
|
|
|
Why the heck would you put 25,000 records (or more!) into a GridView? Do you expect your users to look at them? And perhaps work out which one of them they are actually interested in? Would you want to sit there and do that?
And if your users aren't going to look at all those, then why are you wasting time, memory and space loading this into a GridView?
Instead, look at where you are getting this data from, and transfer that directly into Excel - that way, it may well be quicker, more efficient and a lot less likely to run out of memory...
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
its better that i transfer that directly into Excel but i dont know how can i do this, just i know bind a gridview and then convert it to excel
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
