I am trying to set the compiler options attribute from a value to blank using the msbuild task of xmlmassupdate. Unfortunately it is only changing the c# (the first one) and not the second one. Does anyone know the syntax for xmlmassupdate to do this?
Your problem seems similar to the one described in here:
Stack overflow: MSBuild XmlMassUpdate Task.
Basically, when you have more than one child node inside a parent, you have to provide a key by which the update is going to find your node using xmu:key attribute like:
xmu:key="nameOfTheAttribute"
where nameOfTheAttribute is the attribute that's identifying the child node
Related
I use pyscipopt. I know how to add constraints while branching using handlers (kind of), but now I also want to change some parameters. I imagine that is similar, but couldn’t found an example.
What I want is as follows: -Every time a feasible node is found (or every 10 nodes for example) update a parameter.
How do I do this? Are there examples or documentation on this?
You should implement an event handler. Look in test_eventy.py for an example. The eventtype should be SCIP_EVENTTYPE_NODEBRANCHED. Then you can change parameters in the exec callback.
When I look at my application state in Vue's devtools chrome extension, I can see multiple instances of the same component in the tree view. However, there is no way to distinguish one instance from another. For example, in the screenshot below there are three <Todo> components. Imagine instead there are 30. How do I attach some kind of instance name or id to my components? It seems silly to have to click through 30 components to find the one I need.
I had the same idea also a couple of months ago.
So I gave it a try.
My PR has been submitted: https://github.com/vuejs/vue-devtools/pull/331
It's probably a bit early to rely on my solution since the core team could still reject the PR or request other naming conventions.
Until then you can build my proposal version yourself from my repo:
https://github.com/nerdyglasses/vue-devtools/tree/verbose-component-tree
Is that helping you?
Best, Christian
You can use the ':key' attribute. And you even HAVE TO use it if your component depends on a v-for loop.
here you can see the keys
I am in charge of maintain some build scripts intended to be used with MSBuild; I have found that they have several properties, among them I found the code:
/p:PipelineDependsOnBuild=False
Looking for an explanation about this, I search the web and I found that is part of the solution of issues with the building process of web projects, but is used in combination with other properties.
So far I have not found an msdn page that explain the purpose of that.
Fact: I tried to search for /p:PipelineDependsOnBuild=True and no results were found
For future reference, as I too found the use of this particular property curious, yet can't find any reference myself. However, in the said Microsoft.Web.Publishing.targets file, this comments are interesting:
"These two Properties are not compatable %24(UseWPP_CopyWebApplication) and %24(PipelineDependsOnBuild) both are True.
Please correct the problem by either set %24(Disable_CopyWebApplication) to true or set %24(PipelineDependsOnBuild) to false to break the circular build dependency.
Detail: %24(UseWPP_CopyWebApplication) make the publsih pipeline (WPP) to be Part of the build and %24(PipelineDependsOnBuild) make the WPP depend on build thus cause the build circular build dependency. " />
So that using the PipelineDependsOnBuild=False might be necessary in order to using `UseWPP_CopyWebApplication' option.
I want to evaluate my content blocks before running my test suite but the closures' property names is in bytecode already. I'm ooking for the cleanest solution (compared with parsing source manually).
Already tried solution outlined in this post (and I'd still wind up doing some RegEx/parsing) but could only get it to work via script execution engine. It failed in IDE and GroovyConsole. Rather than embedding a Groovy script in project's code, I thought I'd try using Geb's native classes.
Is building on the suggestion about extending Geb Navigators here viable for Geb's PageContentSupport class whose contentTemplates contain a LinkedHashMap of exactly what I need? If yes, would someone provide guidance? If no, any suggestions?
It is currently not possible to get hold of all content elements for a given page/module. Feel free to create an issue for this in Geb's bug tracker, but remember that all that Geb can provide is either a list of content element names or a map from these names to closures that create these elements.
Having that information isn't a generic solution to your problem because it's possible for content elements to take parameters and there are situations where your content elements will be available on the page only after some other actions are performed (for example you have to click on button to reveal a section of a page that uses ajax to retrieve it's content). So I'm afraid that simply going over all elements and checking if they don't throw any errors will not cut it.
I'm still struggling to see what would "evaluating" all content elements prior to running the suite buy you. Are you after verifying that your content elements still work to get a faster feedback than running the whole suite? I'm pretty sure that you won't be able to fully automate detection of content definitions that don't work anymore. In my view it will be more effort than it's worth.
I'm new to WiX installer but I need to solve a situation. After searching for some time I haven't found any solution.
I need to read a value from SQL Server while running the WiX installer and keep it, but I'm not sure if it is possible. All I've found are 'updates' or 'insert' query examples, but no 'select'.
Has someone done something like this?
When you need to read something from somewhere during the installation process, you have several options:
if it has a trace in the registry, then RegistrySearch is the proper choice
if it has a file installed to the well-known location, then DirectorySearch/FileSearch approach fits best
otherwise, you always have the last resort - a custom action
Obviously, if you need to read something from SQL Server, custom action is the only choice for you. So, to tell it short, you should create an immediate custom action which will read the data you need and place it to the property (or a number of properties). You should use this property later in your installation.
Try to avoid custom actions as much as you can, but if you have no other choice, still try to find the tested ones. For this particular case, take a look at the Community MSI extensions.
Although you might solve this particular problem fast, I would still encourage you to dive deeper into the topic and understand how Windows Installer (the underlying technology behind WiX Toolset) works. Start from MSDN.
You could use the registry extended stored procedures to insert the value you need into the registry and then do a Registry search to pull the values into your installer.
As the blog post says the sp's are undocumented and thus unsupported but if it works for you it will save writing a custom action.