 |
|
Apologies for the shouting but this is important.
When answering a question please:
- Read the question carefully
- Understand that English isn't everyone's first language so be lenient of bad spelling and grammar
- If a question is poorly phrased then either ask for clarification, ignore it, or mark it down. Insults are not welcome
- If the question is inappropriate then click the 'vote to remove message' button
Insults, slap-downs and sarcasm aren't welcome. Let's work to help developers, not make them feel stupid.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
For those new to message boards please try to follow a few simple rules when posting your question.- Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
- Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
- Keep the subject line brief, but descriptive. eg "File Serialization problem"
- Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
- Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
- Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
- If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode "<" (and other HTML) characters when pasting" checkbox before pasting anything inside the PRE block, and make sure "Use HTML in this post" check box is checked.
- Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
- Please do not post links to your question into an unrelated forum such as the lounge. It will be deleted. Likewise, do not post the same question in more than one forum.
- Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
- If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
- No advertising or soliciting.
- We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Please help me...
objCreateMasterBenefit.CreateMasterBenefitDocument return SpreadsheetDocument how can I output so users can choose to save/open doc in web apps...
Dim MemoryStream As New MemoryStream
Try
Response.ClearHeaders()
Response.ClearContent()
Response.Clear()
Response.Buffer = True
Response.ContentType = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml" Response.AddHeader("content-disposition", "attachment; filename=" & lblEditedPlan.Text)
Response.Charset = ""
Me.EnableViewState = False
objCreateMasterBenefit.CreateMasterBenefitDocument("Master_Benefit_"".xlsx", MemoryStream, groupID, planID, SequenceNumber)
MemoryStream.WriteTo(Response.OutputStream)
Response.Flush()
Catch ex As Exception
Throw
Finally
MemoryStream.Close()
MemoryStream.Dispose()
End Try
Response.End()
Response.End()
|
|
|
|
|
I just notices most of the blogs I used to follow are no more updated by they creator.
What are the good .NET / C# / Application Lifecycle blogs with RSS feed of this moment. I prefer to follow people than organizations. I like blogger that write one article, news or tutorial by weak or month.
Thank you,
|
|
|
|
|
You have to go and look for them. There are many here on CodeProject, but if you want others then they could be anywhere.
|
|
|
|
|
Whilst prototyping a console app the other day, it stuck me that the dynamically linked library seemed somewhat redundant in .NET and that was nothing I could do with one that could not be achieved by creating an executable. I can add a reference and reuse publically declared types whilst with both. But an executable has some obvious benefits, yet I've always created DLLs because I've been told 'it's best practice' or just followed other's examples.
Can anyone think of a technical reason why you'd choose to build a library over an executable? Is a DLL an artefact simply for some legacy backwards compatibility that I'm unaware of?
Thoughts?
|
|
|
|
|
CatchExAs wrote: But an executable has some obvious benefits,
Like what? 
The only "benefit" an executable has over a library is that it can be executed directly. For the vast majority of class libraries, executing them doesn't make any sense.
For example, what would you expect to happen if you executed mscorlib? System.Data? Etc.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
What if you required that they tested and verified themselves?
|
|
|
|
|
What do you mean by "tested and verified themselves"??
|
|
|
|
|
Say, main() by default was required to call a bunch of test suites that executed unit tests. I once worked somewhere where they did this btw.
|
|
|
|
|
Soooo, you're going to ship your unit tests with the code to the customer? That sounds stupid. That's like shipping the Paint Shop from the assembly plant with the car that it built.
|
|
|
|
|
Sounds more like including the diagnostic reader device with the car rather than requiring a visit to the shop when the check engine light comes on.
|
|
|
|
|
When was the last time you executed unit tests on customer site?
I've written seperate tools to diagnose database problems, but never to verify "the code". If the .EXE gets corrupted, chances are good it won't even run, and if it is corrupted, chances are good you've got hardware problems.
|
|
|
|
|
I never write or execute unit tests at all, anywhere.
I don't have the same concerns as the OP and I don't think we're talking about DLLs shipped with an application, but libraries provided to other developers for use in their applications -- like if I wrote an ISO 8601-compliant date handling library for example, but only distributed the DLL rather than the code.
Personally, when I get a DLL from some third-party (an ADO.net provider perhaps) I don't like having to create a Solution and Project, then add a reference just so I can use the Object Explorer to see what's in it. It would be convenient if it were an EXE and running it would provide (version-specific) documentation and such (hopefully more accurate than what's available on the developer's website, if any). Additionally, the Object Explorer only says what's in there, not how to use it, no documentation.
I suspect there must already be a tool that allows sort of a command-line Object Explorer, but I haven't looked. Certainly one could be written, but it still wouldn't provide everything that a custom baked-in tool would.
Seeing that given a DLL with some (public) class C with a (public) method M that takes a string parameter S and returns a string is all well and good, but wouldn't it be convenient to immediately be able to execute:
somelib test C.M "hello world"
and have it report the result? Without having to access an IDE and write a simple test app just to see what it does?
|
|
|
|
|
Or a compiler that bootstraps and tests itself?
Or an installable that operations can't f*** up?
There are always reasons for questions 
|
|
|
|
|
CatchExAs wrote: Or a compiler that bootstraps and tests itself?
Really? How often do you see that and how often are you going to use it?
CatchExAs wrote: Or an installable that operations can't f*** up?
Depending on what you mean by "operations", yeah, right. If you're talking about people, there's nothing they can't f*** up and there's always some situation that you're code isn't going to be able to recover from.
|
|
|
|
|
Dave Kreskowiak wrote: Really? How often do you see that and how often are you going to use it?
True, you see it rarely. But it is a useful technique to some, and so might be useful to others. You wouldn't know until you tried it.
Dave Kreskowiak wrote: Depending on what you mean by "operations", yeah, right. If you're talking about people, there's nothing they can't f*** up and there's always some situation that you're code isn't going to be able to recover from.
Of course, which is why we automate things in the first place but the point is that the deployed binary can run tests on itself 'in situ' rather than a test environment which may or may not be representative of the target production environment.
|
|
|
|
|
CatchExAs wrote: Can anyone think of a technical reason why you'd choose to build a library over
an executable?
..because the code is not an executable; that's the reason I did not include an entry point.
If I put a logger into a separate assembly, I can easily swap it with another, without ever touching the executable. The logger-class does not need to run independently of the main executable. Same goes for most code.
And yes, I've got some private projects where I use executables as if they are DLL's; it's just a collection of code after all.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
One thing I have considered (but never actually done) is to have a library as an EXE so it can print out documentation (to the console) and maybe allow testing and demoing the functions contained therein.
<aside>
In OpenVMS, the analog of a DLL is a "shared executable", which generally has an EXE extension.
</aside>
|
|
|
|
|
My thinking was along similar lines i.e. writing small executables that did one thing but did it well a la UNIX.
Except I would require that the default behaviour of a main() function was to run a test suite embedded in the assembly.
|
|
|
|
|
You can have a static int Test(string[] args) for that (unless you plan on using debug, vs stdout). Call it with the help of a shell-extension or external command that loads the assembly and executes your custom entrypoint 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Having a separate console app that loads the Assembly would definitely be another way, but the only reason would be to simply remove the main, I don't see a big benefit.
|
|
|
|
|
I was thinking:
myProgram.exe -> runs a test suite
myProgram.exe /run -> runs a traditional program if implemented or returns if it's a library
|
|
|
|
|
That sounds kinda backward to me.
|
|
|
|
|
PIEBALDconsult wrote: I don't see a big benefit.
You'd be separating the "testing" code from the code being tested. Better yet, put it in your own class, as opposed to the Program class, and get the benefits of inheritance.
I can see how one would create an application that executes SQL from the command prompt, and references this as if it is a library to get the appropriate databaseclasses.
Then again, you don't want to be referencing a WinApp application from a Webapplication and have it load the complete Forms-environment and all its dependencies.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
