ofek shilon - Developer IT

Setting a VCProject property to default

- by Ofek Shilon

I'm trying some VS2005 IDE macros to modify a large amount of projects (~80) within a solution. Some of the properties I wish to set do expose a programmatic interface to 'default', but many others do not. Is there a generic way to set such properties to their default? (eventually meaning erasing them from the .vcproj file) Simplified example, setting some random properties: Sub SetSomeProps() Dim prj As VCProject Dim cfg As VCConfiguration Dim toolCompiler As VCCLCompilerTool Dim toolLinker As VCLinkerTool Dim EnvPrj As EnvDTE.Project For Each EnvPrj In DTE.Solution.Projects prj = EnvPrj.Object cfg = prj.Configurations.Item(1) toolLinker = cfg.Tools("VCLinkerTool") If toolLinker IsNot Nothing Then ' Some tool props that expose a *default* interface' toolLinker.EnableCOMDATFolding = optFoldingType.optFoldingDefault toolLinker.OptimizeReferences = optRefType.optReferencesDefault toolLinker.OptimizeForWindows98 = optWin98Type.optWin98Default End If toolCompiler = cfg.Tools("VCCLCompilerTool") If toolCompiler IsNot Nothing Then ' How to set it to default? (*erase* the property from the .vcproj)' toolCompiler.CallingConvention = callingConventionOption.callConventionCDecl toolCompiler.WholeProgramOptimization = False toolCompiler.Detect64BitPortabilityProblems = False End If Next End Sub Any advice would be appreciated.

Read the article

Adding WCF service reference adds DataContract types too

- by Avi Shilon

Hi everybody, I've used Visual Studio's Add Service Reference feature to add a service (actually it is a workflow service, created in WF4 RC1, but I don't think this makes any difference), and it also added the DataContracts that the service uses. At first this seemed fine, because All I've had in the DataContracts was simply properties, with no implementations. But now I've added code in the constructor of one data contracts that initializes creates an instance of one of the properties that exposes a list of other DCs, and when I've updated the service reference via VS (2010 RC1), the implementation was not updated. What should I do? Should I use my DCs instead of the ones created by VS or should I use the ones VS created? I've noticed that the properties in the VS-generated DCs contain some additional logic for checking equality in the setters and they also implement some interfaces too (like IExtensibleDataObject and INotifyPropertyChanged) which might get handy I guess in the future (I'm not knowledgeable at WCF). Thank you for your time folks, Avi

Read the article

Filter tweets by client name

- by Ido Shilon

I'm trying to filter tweets results by client name like - using source operator. I'm trying to do it with a a client named "single platform" , to get tweets like http://twitter.com/#!/phoenixparknyc/status/43340419475570688 but the search doesn't seems to work (tried with quotes as well) http://twitter.com/#!/search/source%3Asingle%20platform%20Specials%2FEvents%20 Any idea how to make the search works ?

Read the article

Controling CRT memory initialization

- by Ofek Shilon

Occasionally you meet bugs that are reproducible only in release builds and/or only on some machines. A common (but by no means only) reason is uninitialized variables, that are subject to random behaviour. E.g, an uninitialized BOOL can be TRUE most of the time, on most machines, but randomly be initialized as FALSE. What I wish I would have is a systematic way of flushing out such bugs by modifying the behaviour of the CRT memory initialization. I'm well aware of the MS debug CRT magic numbers - at the very least I'd like to have a trigger to turn 0xCDCDCDCD (the pattern that initializes freshly allocated memory) to zeros. I suspect one would be able to easily smoke out nasty initialization pests this way, even in debug builds. Am I missing an available CRT hook (API, registry key, whatever) that enables this? Anyone has other ideas to get there?

Developer IT