I'm toying with api platform and just saw that it comes with a client generator command.
When I run it a second time it has no effect because files have already been generated.
But, in the case of a custom template, if I want to re-run the client generation but want to achieve an update is there anything I can do?
At the moment the only way that I have found is to delete the directories created and run the command, but it is not e nice solution..
The client generator is designed for scaffolding only. It is intended to bootstrap your project, then it will never try to update the existing code.
At the moment the only way that I have found is to delete the directories created and run the command, but it is not e nice solution..
It's the only solution for now. We may introduce a new --overwrite flag (Pull Request welcome), but internally it will do exactly the same thing.
Related
I added a framework to my project in Xcode written in Swift. There was some issue in the framework so I tried to modify and a dialog came out giving me the option to lock or unlock, so I choose Unlock and proceed.
Would it harm the owner? Would these changes continue with my project until my app is in the App Store? Please let me know if there is an issue with that and help with a solution.
Simply I need all framework files but I don't need all functions. In addition, I need to add functions to fit to my project.
It is not recommended to modify a third party pod's code, as it will be overwritten with the next pod update.
There are multiple solutions you can try:
implement the framework manually and modifying it there (keep in mind that you are losing the capability of quick updating)
modify it as an extension of the framework if possible, i. e. store your changes in a separate file and paste it everytime an update occurs (not recommended as it is not too convenient)
fork the project and make changes on that separate fork
create a pull request to the project that includes the modifications (if you think they are helpful for others as well)
I'm writing a unified project for 3 smart TVs. I have also 3 configurations created in Visual Studio. Now I want to execute some CLI scripts depending on selected configuration.
The problem is in new ASP.NET 5 project I don't have an editor for post build events.
I know I have to do this in project.json. What I found is:
"scripts": {
"postbuild": ""
}
But using this one I can't create different CLI scripts for different configurations.
I found also:
"configurations": {
},
And I guess this is probably what I want, but... How to use it? Intellisense has no power here and also I wasn't lucky searching the Web...
[edit]
Maybe I should try with .xproj?
You'll need to build a master script which uses the available context and environment variables to switch and run the other scripts of your choice.
In addition to the list of variables Here for compile, you also get these for publish related scripts and then these are available everywhere, as are environment variables returned by Environment.GetEnvironmentVariable, which can be seen here.
The image below shows the intellisense from the VS2015 Update 3 RTM, but it's misleading, since you get others depending on the script block you're using:
So, your full list of context variables that you can use to control flow in your scripts is:
Every script block:
%project:Directory%
%project:Name%
%project:Version%
Compile specific:
%compile:TargetFramework%
%compile:FullTargetFramework%
%compile:Configuration%
%compile:OutputFile%
%compile:OutputDir%
%compile:ResponseFile%
%compile:RuntimeOutputDir% (only available if there is runtime output)
%compile:RuntimeIdentifier% (only availabe if there is runtime output)
%comiple:CompilerExitCode% (only available in the postcompile script block)
Publish specific:
%publish:ProjectPath%
%publish:Configuration%
%publish:OutputPath%
%publish:TargetFramework%
%publish:FullTargetFramework%
%publish:Runtime%
I investigated on this a bit but did not really get to any good result.
There are some project variables that are exposed in scripts. Unfortunately, those are very limited:
%project:Name% gives you the project name
%project:Directory% gives you the project directory
%project:Version% gives you the project version
So there is no way to access the build configuration or the environment here.
The configurations option in the project.json is also limited to build configurations and only allows declaring compilation options there, so that also doesn’t work.
Unfortunately, there also doesn’t seem to be another way to solve this. At least not right now. I would consider myself sending a pull request to DNX to add some additional project variables which one could use but at the moment, it doesn’t really make any sense to invest time into DNX: After all it’s being replaced by the dotnet CLI. We’ll see if that one will come with functionality to access the environment—and if not, I might end up submitting a pull request to add this functionality. But until we get there, I’m afraid there is no solution for this.
I have created database project in visual studio 2013 from existing database. Then I have done lot of changes in database project like modify stored procedures, post deployment script, table structure, etc . Now database project is ready to deploy. But I am worry if any script fails then How I can retain the original state though it build properly.
Please suggest that if any query fails then I want ROLLBACK the all changes that I have made in database project.
Firstly you need to trust your tools and either believe they will work or find other tools.
While you are building the trust I would add a create backup to the pre-deployment script or run a backup before you deploy then if anything goes wrong you can restore and figure out what went wrong.
As David said to roll-back, you would get the previously deployed dacpac and generate a new deployment script from that but fixing forward is almost always the correct thing to do rather than rolling back to a previous version.
ed
Have you been checking your changes into version control? If so, all you need to do is to revert back to the last known good version.
Or... simply work out why it's failing now and fix the root cause?
I used Db projects some time ago and as far as I remember the deploy script was wrapped in a transaction. It is possible to generate sql script without executing it. That setting was somewhere in DB project settings. You can take a look inside that script and make sure that it'll rollback on error.
Doing a backup would still be a recommended practice especially when you deploy to production.
when working on important scripts I developed a habit of always starting a transaction and commenting out the commit.
If you accidentally run it, it won't take effect. The commented out commit would only come out when the thing was done.
While this answer indicates that you CAN revert in source control (Assuming SSDT at this point) it would be nice to get a pointer to the exact process to do this. On a file by file basis the history works the same but how to revert the entire database at once isn't immediately obvious.
I want to create a simple autoupdate that downloads the new version of my software (in a temp folder), runs the installer (I'm using Innosetup) which will take care of closing my application and then, after the setup is complete, I would like to remove the installer file.
What's the best approach to do that?
I saw there are a number of libraries that take care of everything but I have written almost all the code used to check for updates and I'd just need to be able to run the installer.
Thanks a lot.
You can use the NAppUpdate framework to achieve that quite easily.
Check this out: http://www.sjurvarhaug.com/nappupdate-to-automatically-download-and-execute-installer
I'm creating a module that requires a few things to be done (once only) when the module is installed. There may be a number of things that need to be done, but the most basic thing that I need to do is make an API call to a server to let the external server know that the module was installed, and to get a few updated configuration items.
I read this this question on stackoverflow however in my situation I truly am interested in executing code that has nothing to do with the database, fixtures, updating tables, etc. Also, just to be clear this module has no affect (effect?) on the front end. FYI, I've also read this spectacular article by Alan Storm, but this really only drives home the point in my mind that the install/upgrade scripts are not for executing random PHP.
In my mind, I have several possible ways to accomplish this:
I do what I fear is not a best practice and add some PHP to my setup/install script to execute this php
I create some sort of cronjob that will execute the task I need once only (not sure how this would work, but it seems like it might be a "creative" solution - of course if cron is not setup properly then this will fail, which is not good
I create a core_config_data flag ('mynamespace/mymodule/initialized') that I set once my script has run, and I check on every area of the adminhtml that my module touches (CMS/Pages and my own custom adminhtml controller). This seems like a good solution except for all of the extra overhead every time CMS/Pages is hit or my controller is hit, checking this core_config_data setting. The GOOD thing about this solution would be that if something were to fail with my API call, I can set this flag to false and it will run again, display the appropriate message, and continue to run until it succeeds (or have additional logic that will stop the initialization code after XX number of attempts)
Are any of these options the "best" way, and is there any sort of precedent for this somewhere, such as a respected extension or from Magento themselves?
Thanks in advance for your time!
You raise an interesting question.
At the moment, I am not aware of a means to go about executing any arbitrary PHP on module installation, the obvious method (rightly/wrongly) would be to use the installer setup/upgrade script as per 1 of your Q.
2 and 3 seem like a more resource intensive approach, ie. needlessly checking on every page load (cache or not).
There is also the approach of using ./pear to install your module (assuming you packaged it using Magento). I had a very quick look through ./downloader/pearlib/php/pearmage.php but didn't see any lines which execute (vs copying files). I would have imagined this is the best place to execute something on install (other than 1 mentioned above).
But, I've never looked into this, so I'm fairly interested in other possible answers.