|
Hello, I am Vikash Gohil
I want to know that whether the CR redistributable MSI that Comes with VS2005, is a Licenced Software?
And Since it comes with VS2005, and gets installed when installing VS2005, does it mean that it is part and parcel of the VS2005, a Microsoft Product.
Also from where Can i download CRRedist_86.msi file from Microsoft Web Site.
|
|
|
|
|
Licensing and support for Crystal Reports for Visual Studio[^]
I don't know if the redistributables are downloadable separately, but
they are included with visual studio. In VS 2008, I found them here:
C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\CrystalReports10_5
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Greetings.
I need to write and read information from the PCI port in a PC.
Is there a dll that allows me to do this?
Thanks
|
|
|
|
|
There's no such thing as a PCI "port". There's the PCI expansion bus, which you normally never talk to. You talk to the devices on it directly. Same thing with USB.
|
|
|
|
|
|
|
I have looked at System.Transactions but was unsure if this would accomplish my goal. If this is the way to go, do you know of any good examples of how to implement this? I've been reading through that page for sometime but can't quite figure out how to get a working solution.
Thanks for the response
|
|
|
|
|
Try here[^]
only two letters away from being an asset
|
|
|
|
|
Hi all
I am trying to uninstall from the GAC an assembly.
I use gacutil /u MyAssembly.dll
Once I have done this, I expect that in
c:\Windows\assembly
MyAssembly.dll is gone,
but is still there.
What I am doing wrong?
Thanks
Man
|
|
|
|
|
I don't know if this is the cause of your problem, but gacutil (on MSDN)[^], read the third paragraph on the '/r' option in the err... Options table.
Hope this helps!
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
All you did was unregister the .DLL. It won't remove the .DLL file from the folder. You have to remove that yourself.
|
|
|
|
|
Go to window/assembly folder . Right click on your installed assembly and select unstall option from menu. Assembly will be uninstall along with remove from registry.
|
|
|
|
|
How do you bulk multiple INSERT statements? Suppose I fire a bunch INSERTs in the form of SqlCommands, how do I make the server execute them in one batch, rather than one by one? Is there a simple solution, or do I have to drag the entire ADO.NET library into the picture?
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
There's a bunch of examples of this out on the web. All you have to do is search[^].
Also, you might find this[^] to be quite interesting.
|
|
|
|
|
Yeah, I found those, but they all required me to use the whole ADO.NET stuff. I found some code from the nHibernate project that I'm going to use instead.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Have you look at LinqTOSQL or Entity Framework?
only two letters away from being an asset
|
|
|
|
|
Indeed I have, which is why I'm looking for batched inserts.
Oh well, I found a really good solution (mentioned above) that will cover my needs. I'm going to keep the Linq to SQL code (commented out), if they ever optimize inserts.
I just did a comparison using Linq to SQL and the nHibernate code, and the difference was staggering. 20+ seconds compared to less than a second (I have no quantitative figures here, but let's just say that I never say the progress bar). Now I have about 30 entities or so to convert into the new scheme...
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Jörgen Sigvardsson wrote: 20+ seconds compared to less than a second
I assume you mean LinqToSql vs. nHibernate?
only two letters away from being an asset
|
|
|
|
|
Yeah. Well, not nHibernate as is. They have this SqlCommandSet that can batch SqlCommands together.
Linq to SQL is only really useful when editing and querying small amounts of objects, IMHO. That's mostly the case for me, but this is a special case that needs to be adressed. Damn shame I can't do it in pure Linq.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Together with reading Joe Duffy's 950 page comprehensive guide to "Concurrent Programming in Windows",
I recently came across the following website that cleared the fog from my eyes as to what is going on in a multi-threaded application:
http://www.albahari.com/threading/
Reading all this in detail and coming to terms with the implications, highlights a major concern I have as a professional developer about building anything at all using multi-threading.
With a simple single threaded application any developer can reliably design class diagrams and simple flow diagrams for example, and reliably test it by stepping through a known and predictable path of execution and running it just once. The paths of execution are known and can be throughly tested.
The whole assumption of multi-threading has been you know exactly what you doing and always get it right. You will get no help from the compiler, you get a random path of execution due to the thread scheduler's non-deterministic (random) behaviour, all the error handling and logging in the world will never once tell you that you missed a single lock in a million lines of code. In fact, there is no tool available to test multi-threading in shape of form at all!
Once you've installed the application, when you get unexplained crashes, you can debug by stepping through the application with the same data that created the error and not once ever find the error as there could be millions of paths of execution, which is the weird behaviour every developer has felt stepping through the application time and again, jumping from thread to thread, but never in the same place twice!
Given that we can't reliably design and test an application with multi-threading, why on earth should anyone expect that we can build reliable applications with it?
Even if I now felt confident enough to now go build a multi-threaded application, no matter how well I designed it, any future errors introduced by another developer would never ever be found.
If that doesn't scare you enough, I (or anyone else!) could take look through your code, remove any single lock in a million lines of code and all the exception handling and logging and testing in the world will never help you find one of the simplest types of multi-threaded errors, let alone any of the vastly more complex defects that can occur!
Once you understand that missing locks on static data values can lead to corrupt data, i hope you feel as uneasy as i do.
I would like someone to challenge my assertion that .NET multi-threading undermines the ability of developers to produce reliable applications with reliable data.
This strikes me as a fundamental flaw in most developer's assumptions of what we up against and a fundamental flaw with multi-threading as there is no way to reliably to design or test for multi-threading errors. There is equally no way to even find the source of any errors when we get unexplained crashes or random data, and that is assuming you even realise yet how high I expect the probability is that you already have random data given the staggering complexity of this architecture and how hard it is to get right without any help from any normal tools that developers have come to depend on!
|
|
|
|
|
Justin Fox wrote: Given that we can't reliably design and test an application with multi-threading, why on earth should anyone expect that we can build reliable applications with it?
A thread is a single path of execution, for example, the actions that you perform. We can test this list of actions like it's a single thread.
Put more people in the room, and you'll get a problem with shared stuff. For example, if I enter the room then you'd best not touch the coffeemachine.
You can test my path of actions, you can test your path of actions, but you'll have to lock the coffeemachine because you can never know when our two lists of actions collide (we might grab the coffeemachine at the same time).
|
|
|
|
|
It's not so much a flaw of multithreaded applications, as it is a flaw in designing applications that rely on side effects. Have a look at the work that Microsoft are doing in Axum[^], to see why multithreading requires a complete shift in the way you look at developing applications.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I should clarify that the newer ways of working with threads the .NET have introduced, such as Background Worker threads, PLINQ, etc, ensure that there is less expected of the developer, so using these new options appear to be far more controlled, so I should have made that more clear up front.
When to use threads and when not to as highlighted in www.albahari.com/threading is something I will be following in future.
My concern is around the use of allowing someone to spawn new Threads everywhere without something to check what he is doing and identify how bad it gets very quickly! Add in a mix of synchronisation, but also mis-applied, with extra dependancies to other classes and extra sleep delays to compensate for being completely in the fog, and it produces the perfect application where defects lurk in ever corner, but don't get detected until run in live production a million times over!
|
|
|
|
|
I think you're blowing this WAY out of proportion.
You make is sound as though you're walking through a dense minefield every time you think of launching a new thread. That's just not the case. If you understand how to do threading properly and take the proper precautions around making sure that shared access is properly maintained, you'll never have a problem. All of the horror stories you here over this are because things were not done properly or something was missed along the way and an avenue of potential failure was left in the code.
With proper planning and thorough investigation, this isn't a problem. There are thousands of multi-threaded apps in production that never have an issue. So what are you worried about?? The only thing that's scaring you is that you haven't done it yourself and your skill set doesn't include the knowledge of how to manage proper threading.
|
|
|
|
|
I fully recognise there are whole teams of developers out there that can design flawless designs knowing they need to keep it simple. Equally, I recognise that there are plenty of other simpler options for most cases that you practically roll out the box. That is fine and I recognise that I will be getting responses from developers who do know way more than me on this. Fine.
What about when you come across an over complex design that you know to be flawed where clearly the designer didnt realise that it is a seriously bad idea to just spawn threads everywhere? Are you so sure that you want to turn a blind eye just because the compiler doesnt throw any errors and all your error handling reports nothing? How confident would you be over your data? Can you trust that some other junior doesnt come alone and unknowingly just add some static data? And that no matter how many times you point out how fundamentally flawed a design is to a manager, since there is no evidence of an error, there is no error?
Am i making any sense?
|
|
|
|