Android Studio 2.1.2 deletes appengine-generated folder each rerun of the backend module. Making the local debug pretty tiresome (I think it didn't happen in previous versions, but not sure).
How can I make the local DB not to be deleted?
This answer worked for me.
basically you need to just make sure to store your db file in a different folder than the exploded-app.
Related
I have a WPF application which i publish in intranet, the thing is i published the application 20 times till now, so i have 20 folders and the size of the build becomes more, i manually delete and leave only 2 latest versions, but is there a way to only have latest version to be published?
Right now i save in folder and then copy to inetpub\wwwroot, but if i had to send the files directly using Visual Studio, i have speed issues due to weak intranet lines in some branches.
but is there a way to only have latest version to be published?
You are already only publishing the latest version each time you publish.
The older versions don't magically disappear when you publish a new version though. You'll have to remove them manually one way or another:
Can ClickOnce be configured to delete off old published directories?
Actually when u publish only current and previous version source are there in application files,Visual studio publishing tool doesnt delete the older versions in published folder ,so we are seeing too many folders .Just delete everything in publish folder before publsihing and you will have only two folders current and previous version.
In our current dev. workflow there is main database --> DbMain. There is the process that takes the latest version of the project and automatically deploys it there and after that it triggers unit tests. As we would like to always have working version of the project in the source control each developer should be sure that he checks in the working code and all tests would be passed.
For this purpose we decided to create individual databases for each developers that has following naming convention --> DbMain_XX (where XX are the developers initial). So every developer before the check-in is suppose to publish all the changes to that database manually and run the unit tests. It is useful to setup publish config for this purpose with that is the copy of the main publish config with the only difference in the database names.
That would introduce that we will have a lot of different publish profiles in the solution that is quite a mess.
If we will not add these profiles to the source control, then .sqlproj file would still have reference to these files so the project will have reference to the not existing files.
So the actual question. Can I have single publish profile for all developers where the database name will be changed using variables? For example DbName_$(dev_initials)? Or can we have that each developer would have their own publish configs only locally and it wouldn't break the project?
UPDATE:
According to the Peter Schott comments:
I can create local publish profile, but if I don't add it to the source control, then the still be an entry in sqlproj file, but the file itself will be unavailable.
Running tests locally have at least 2 disadvantages. The first one is that everybody is supposed to install SQL Server locally. We are mainly working via virtual machines and the disk space is quite limited there. Another thing is that developers will definitely forget or not will not run tests manually every time. Sometimes they will push changes to the repo without building it or/and running tests. We would like to avoid such situations and "catch" failed build as soon as possible.
Another approach that was mentioned is to have 1 common build database. And in my case we have one (DbMain). All of developers can use it for it's needs but we will definitely catch the situation when the 2 developers will publish at the same time and that can make a lot of confusion by figuring out what's really went wrong.
A common approach to this kind of thing - not only for SSDT publish profiles but for config files in general - is to commit a generic version of the file with a name something like DbMain.publish.xml.template, and provide instructions to the developer to rename the file to DbMain.publish.xml - or whatever - and .gitignore this local copy of the file, allowing the developers to make whatever changes they want, but inherit the common settings from the .template version of the file.
Publish profiles don't need to be added to the .sqlproj to be used at deploy time, this is merely a convenience in Visual Studio to make them easier to find and edit, so you don't need to worry about broken references.
You are right in wanting to avoid multiple developers publishing to a common "build" database, this is a recipe for frustration.
Really, you want the "build" database to be published to as part of your CI process, meaning after the developers have pushed their changes.
I'm new to this workflow using Git, and I feel like I'm missing one piece of information that's just not obvious to me. I setup a sandbox on Pantheon and did a Drupal install thru Pantheon. Works fine on dev. Then I cloned it to my local, but when I open my local up in a browser it wants to install Drupal, like it was never setup on Pantheon. My best guess is that it's not pulling the database, can't find it, and figures it's a fresh install. But how do I connect the dots here? Thanks!!
You are correct, the database does not pull down with git, only code.
You will either need to manually download the database from their UI or use their command line tool named Terminus. If you're comfortable with the command line, Terminus is the most convenient.
Another option would be to use Kalabox. This is a local dev environment tool which was just released. I haven't tried the latest release yet but have read users reporting it integrates with Pantheon nicely.
We have an net 4.0 winforms application that we publish with clickonce to the client pc's. The installation is about 80 MB. The application is offline available and the update occurs in the startup of the app using
ApplicationDeployment.CurrentDeployment.Update
Each time we do an update of the application everything works fine and each client gets udpated. However the application cache keeps growing in size... We noticed that more then two versions are kept in the LocalAppData folder. The size of the clickonce installation folder is more then 1GB.
ClearOnlineAppCache works only for online applications and we don't find any information to clean the LocalAppData for offline application.
Is there any way to manage previous versions of our application in the LocalAppData folder from our client pc's?
Update:
We removed our custom update code and used the update mechanism of the Clickonce framework. Now old versions are removed properly and only two versions are kept in LocalAppData. I have still no idea why all versions are kept when we update through the custom update code.
I've seen this issue before, but I clarified with the ClickOnce lead at Microsoft before answering.
It keeps two versions of the deployment plus there are extra folders for each assembly. When processing an update, ClickOnce figures out which files have changed by comparing against the assembly it has already cached, and it only downloads the ones that have changed. The deployment folders have hard links to the assemblies in the separate folders. So you might see additional files, but it's not actually the file, it's a link to the files in the assembly-only folders. Explorer will show it as a file, but it's not. So unless you're running out of disk space and are just concerned about the folder size, be aware that the information reported by Windows Explorer may not be accurate.
There is an answer to this problem here
I wrote a function to clean old ClickOnce versions in the client side.
In my machine I've freed 6Gb of space. I don't want to even know the total space used by old versions org wide...
Recently I've been getting more and more into web development and as such have a few questions. I have a few websites that are on a production LAMP server and I've been trying to copy them to my local computer running xampp 1.7.1 on XP Pro. The problem I've been having is mostly path issues. I mainly develop for wordpress, joomla, magento, mediawiki. When I copy the site locally I end up having to change config files and/ or database fields to reflect the local path. The problem I always have is anytime I upload files that contain local paths back up to the server I have to change the paths back to the production paths or I get 'object not found' errors. Remembering the correct paths for each install and what files need to have path updates is a real pain. Is there something I'm missing? Is there an easier way to make sure the paths are correct whether I'm on production or development without having to manually change them every time I upload or download the file or database?
Ideally, you should have a line of code in your main config file which is able to determine what server the code is running on. I use something like the following:
if(__FILE__ === '/home/peter/web_projects/my-project/config.php') {
// set up configuration for development environment
define('DEV', true);
[etc]
}
else {
// code is running on the live server
define('DEV', false);
[etc]
}
This allows me to have the same config.php on my development machine as well as live, and any other files can just check the DEV constant to know if they are local or live.
Yes, what you're missing is an automated deployment system. For linux, there is capistrano, and other such ones, that you may look at (note: I've written one for Windows, but it's not useful for you).