|
Make sure your dll is strongly named before trying to put it in the GAC.
|
|
|
|
|
thank you for your help, i found my dll in the assembly.
|
|
|
|
|
How add launch condition for my deployment to insure that the required registry tree exists and that AutoCAD 2008 or higher version is installed on the client machine?
I am using registry key search and set the launche condition.
In search Target machine node i have added node via Add registry search
in this node of property window i set the property like this.
Name :Search for AutoCAD 2008 RegistryEntry
Property:R17.1
RegKey:HKEY_LOCAL_MACHINE\SOFTWARE\Autodesk\AutoCAD\R17.1\ACAD-6001:409
Root:vsdrrHKCU
Value:AutoCAD 2008
Then in Launch Condition node via right click i did Add Launcd Condtion
and in this property window i have set the value like this.
Name :AutoCAD 2008 Condition
Condition: 17.1
Installurl:
Message:AutoCAD 2008 is not installed in your machine.
After succesfuly builded this setup if run the set up icon the error message
comes out "AutoCAD 2008 is not installed in your machine" where AutoCAD 2008 is alredy installed.
Can anyone guide me plz where i am wrong here.
with regards
tarak
|
|
|
|
|
how to apply jquery effect to dynamic data in asp.net
|
|
|
|
|
You need to reference the jquery javascript in your application. Beyond that, you need to provide more information as to what effects you are trying to apply.
"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
|
|
|
|
|
Hi,
I'm trying to include some user credentials for accessing a remote
webservice. The remote location requires that I use Basic
authentication(RFC2617), which means, from browsing around, I need to include
the user name and password in the HTTP header, but I'm not quite sure
how to access the HTTP header that is sent with the webservice soap
message request.
Can anyone help?
Thanks in Advance.
Kunal Tilak
|
|
|
|
|
|
Very useful. A link to a website requiring registration before you can view the article.
Maybe google result 2[^] would have been more use, as it is accessible to anyone.
|
|
|
|
|
|
for safety reasons the lock object should be private, so nobody can mess with it. That is all there is to it.
|
|
|
|
|
|
all is fine if the outside world cannot touch the lock object, so if you have say a return _collection; somewhere, then the first is no good. Same for the second if you were to have a way to export _collectionLock somehow.
It is good practice to have a private member that is used for locking and locking only. That makes verification a bit easier.
|
|
|
|
|
|
Collin Jasnoch wrote: Why does it need an object just for locking?
it does not. I said "good practice".
|
|
|
|
|
|
Here[^] is 800+ pages of good practice. You can ignore it, and maybe get away with it; or you can learn to appreciate it, but that will take time.
|
|
|
|
|
|
Its a good practice because in most cases you have more than one object you have to sync over threads.
Now if you just use, lets say some list, you have to sync. Its possible to sync everything with the reference to the list object. After 5 months of work, your costumer says he needs some extras. Now how many work do you have if this extras not only need to sync this list but also some other variables (in most cases controlled by this list, but not in all) . Do you really want to lock the list every time you need to access some of this variables?
Thats why its an good practice, cause in the scenario above you do not have to change anything in your locking behavior, if you use an extra object.
Greetings
Covean
|
|
|
|
|
Thanks for sharing!
|
|
|
|
|
Because there are situations where you need one lock to cover operations on multiple objects.
There are also cases where you will be returning the object that you put the lock on. Since you just passed the object to an outside caller, the caller can now try to lock on that object as well, but it'll hang since there's already a lock there.
To avoid problems such as these, you would normally use a seperate lock object than the objects your are actually working with.
|
|
|
|
|
In addition to Luc's postings.
In your example it really doesn't matter if you use the collection itself or create an object for locking.
But how about this example (I just typed it here, not tested, hope you got what I mean):
private object m_objVideoPlayerSync = new object();
private List<string> m_lstVideos = new List<string>();
private EnumPlaybackState m_playbackState = EnumPlaybackState.Stopped;
private void AddVideoToList(string szVideoFileName)
{
lock(m_objVideoPlayerSync)
{
m_lstVideos.Add(szVideoFileName);
}
}
private void PlayNextVideo()
{
lock(m_objVideoPlayerSync)
{
string szVideo = m_lstVideos[0];
m_lstVideos.RemoveAt(0);
m_playbackState = EnumPlaybackState.Playback;
StartPlayBack();
}
}
private void StopVideo()
{
lock(m_objVideoPlayerSync)
{
StopPlayBack();
m_playbackState = EnumPlaybackState.Stopped;
}
}
In the function StopVideo() locking the list of videos would be crude, cause you never do anything on this list, but you need some object to lock.
But doing 2 locks in PlayNextVideo() like
string szVideo = string.Empty;
lock(m_lstVideos)
{
szVideo = m_lstVideos[0];
m_lstVideos.RemoveAt(0);
}
lock(m_objVideoPlayerSync)
{
m_playbackState = EnumPlaybackState.Playback;
StartPlayBack();
}
raises the chance that two threads, both starting the function PlayNextVideo() at the same, would play the same video.
In my first example this would never happen!
Here are some guidelines from MSDN how to use and not to use locks:
In general, avoid locking on a public type, or instances beyond your code's control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:
lock (this) is a problem if the instance can be accessed publicly.
lock (typeof (MyType)) is a problem if MyType is publicly accessible.
lock(“myLock”) is a problem since any other code in the process using the same string, will share the same lock.
Best practice is to define a private object to lock on, or a private static object variable to protect data common to all instances.
I hope this helps you to understand locking a little bit better.
Greetings
Covean
|
|
|
|
|
Luc Pattyn wrote: All is fine if the outside world cannot touch the lock object, so if you have say a return _collection; somewhere, then the first is no good.
If you have a return _collection, you must expose whatever lock object you're using. You may as well use _collection itself as the lock object (and mandate that anyone who does anything with that collection do likewise). Returning _collection without exposing its lock object a guaranteed disaster. The idea that one should avoid exposing the lock for an exposed non-threadsafe object is absurd.
If a non-threadsafe object is accessed by two routines in different threads, the two routines must use the same lock object to arbitrate access. If the routines use different lock objects, nothing will prevent illegitimate concurrent access. I have no idea why this issue doesn't seem to be amplified more.
BTW, I also have no idea why Microsoft didn't come up with a more useful contract for iEnumerable--one that would allow for a collection to accept modifications during enumeration without throwing an exception, provided certain constraints were met.
|
|
|
|
|
you're right all the way.
Exporting a collection that uses a lock but does not make it available is absurd, and making it available is dangerous. Probably best is to provide the required functionality without exporting either the collection nor the lock. I'll have to remember not to start a sentence with "All is fine if".
For collections there should at least be an enumerator that allows modifications to the elements that have already been visited including removal from the collection, so one could e.g. easily remove elements that satisfy some conditions while enumerating them all. I understand it may be hard to come up with an implementation that is safe and inexpensive at the same time.
|
|
|
|
|
Luc Pattyn wrote: For collections there should at least be an enumerator that allows modifications to the elements that have already been visited including removal from the collection, so one could e.g. easily remove elements that satisfy some conditions while enumerating them all.
I would think there should be. Unfortunately, Microsoft's contract for iEnumerable/iEnumerator explicitly forbids them from even allowing such a thing; it requires that an attempt to fetch the next item from an iEnumerator throw an exception if any change has been made to the underlying iEnumerable even if the iEnumerator would otherwise be able to return something useful. Note that the vb6-style "Collection" object does not conform to this but instead returns useful data (hooray!) Too bad no other collections behave similarly.
If I had my druthers, an iEnumerator would be only be required to throw an exception if it couldn't otherwise meet the following contract:
- Any item that exists throughout the enumeration will be returned exactly once in each pass through the enumeration.
- Any item that is added and/or removed during the enumeration will be returned zero or one times (a removal and re-add may create a "new" item) in any pass.
- For collections with keys, changing a key may be regarded as a remove and add, which may be performed in either order.
- Items will be returned in a sequence consistent with the contract (e.g. if a particular collection is supposed to return items in sorted order, adding and deleting items should not cause items to be returned out of sequence).
- If the effect of an addition or removal is observed in one pass through the enumeration, it will be observed in subsequent passes.
For some types of collection, it would be difficult to meet this contract. Such collections should throw exceptions if they're modified during enumeration. On the other hand, if a collection can meet the above conditions even if it's changed during enumeration, why shouldn't it be allowed to?
|
|
|
|
|
I agree, that would be nice to have. I expect MS considers it too complex to sell; the existing stuff is very easy to explain, and they most often seem in favor of dumbing things down... ("You can always clone the collection!")
|
|
|
|