I have a azure app. Is it possible to share it as free aplication(so anyone will be able to deploy it on own azure account) without giving out source code and recompiling it each time. I'm using azure database, so I need connection string to it for making requests and now it string is hardcoded. Also I'm using hardcoded connection string to access to blobs and dynamic instances allocation. Is there the way to take these strings out and allow to change it wihout recompiling project?
Thanks.
Yes, absolutely. When you compile a cloud project, it creates a package file and a configuration file. If you want, you could distribute those files.
Regarding removing connection strings and other settings, one thing you could do is create a separate cloud project that has the same settings as your main cloud project. Only thing is that the settings which are specific to a user environment (like connection strings) would be empty. Then you would package this cloud project and distribute cspkg and cscfg file.
To elaborate further, take a look at the screenshot below:
Essentially here I have 2 cloud projects (Web.Azure and Web.Test.Local) and both of the cloud projects are referencing same Web project. Now in our case Web.Azure is our development cloud project and Web.Test.Local is the test cloud projects. Both of these projects have same settings name e.g. SqlConnectionString. Now in the Web.Azure, I have specified its value to be that of our development SQL Server but in Web.Test.Local I can specify any other value. When we want our testers to test the application, they get the package for Web.Test.Local and they get the settings based on that project. Taking the same analogy, you could have two cloud projects (let's call then Dev and Release). What you have to do is use the same settings in both cloud projects but there won't be any values for those settings in your Release project.
Yet another approach you could take is what's described in this blog post: http://blog.paraleap.com/post/2011/09/13/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.
Please note that cspkg file is essentially a zip file. I could change the extension of the package file from cspkg to zip and unzip that file and see all the binaries. I could then use a tool like RedGate's Reflector or Telerik's Just Decomplie to decompile the binary files and possibly look at the source code. To avoid that, you may want to obfuscate the binaries before packaging them.
Related
I need to deploy a genexus C# in a shared hosting.
I only have access to the ftp, so my idea is put in public_html the files that i have in C:/Models/Project/CSharpModel/web but i don't know if this will work because i never put this archives in a shared hosting, only in a IIS.
Someone can explain me how the genexus will create the database/tables of my application?
There's some else that i have to do?
You need to take of the database reorganization yourself. Keep in mind thou, that GeneXus has a feature called Export Reorganization that will allow you to export a reorganization program, and the doc tells you how to execute that reorg program.
Also, I wouldn't copy the entire web directory in your shared folder. You should use the Deploy Engine in order to get the only minimum required file for your app.
Edit: You need to copy the folder where all the files are placed... commonly there's a folder named after the Deployment Unit's name, and inside that folder, on folder for every deploy you've made. Those folder are named after a timestamp, so you'll easily find the latest deploy.
I recently started building my mobile application using cross-platform Xamarin.Forms toolkit and I'm having a hard time trying to implement some sort of an auto-update mechanism for it.
More particularly, my app has some XML files along with images stored in assets folder, all packed up in the apk file, published to the Google Play.
What I want is to edit and update those xml and assets without publishing a new version of apk in the play store. But I also know that once packed into an apk, these resources cannot be changed unless the user manually downloads and updates the app via the store.
So I currently use the following work around:
I put all of the stuff like XML files or images that I want to update on my server then make an API for specifying their version as well as providing downloadable items.
Inside my app, I have a value representing the current version of the assets. Whenever the app starts, a background process will call the server's API and check if this version value matches the one on the server.
If the versions to not match, the service will automatically download the stuff from the server and store inside user device's internal storage.
Then the app will replace local resources with the resources from the server.
The problem is that this work-around of mine is too clumsy and hard to implement. Any ideas that can help me with a cleaner or more proper solution?
Your logic is correct... if you are "versioning" assets outside of the APK, you need to track a "version" of the local assets vs. the server|remote-based assets and download/cache new assets when the remote assets are newer...
You could use APK expansion (*.obb) files to bundle your "assets" separate from your .apk bundle. But anytime you need to change an .obb (even if it is a patch-based .obb) the application version has to change and thus you have to upload an .apk with a new version to the store even if nothing else in it has changed.
re: APK Expansion Files
The new .aab format (the .apk replacement) allows you to modify individual components of the application and thus the user get a true delta of the differences of what they have installed vs. the new changes resulting in very small update sizes. Again like an .obb, the app's version needs to change and thus a new .aab has to be uploaded.
Note: Xamarin does not currently support direct building of .aab bundles (like Android Studio does), but they can be "handmade" from the MSBuild artifacts.
re: Android App Bundles
Personally for scenarios like yours, I just use a single versioned .zip that includes all the files that can dynamically change between application level version|releases and thus only track that single file (unzipping into local app cache upon download). An version file (or just a file-hash) on the server contains the latest version and URL of the zip file and the zip file itself contains a matching version file. No cached files, download and unzip the file. Upon app update check, compare the version file in the cache to the server version and download/unzip if needed. (Note: I do not even use a separate "semantic version", I just use the SH1 hash of the zip file).
Scenario:
I have two applications, a Windows Forms App and a Windows Service App. The two applications work together, use same libralies (dll) and share the same configuration file (this file is not the app.config but a custom file).
Complications:
I have a website (webforms) where the user will enter information about configuring the software, this information will be saved in the database and from this information will be generated the configuration file. The site should generate build the project with the new configuration file and the page responds to the client's request with a link to download the .msi.
Problem:
How to generate an installer from a command line to be called by the web application after generating the configuration file. I researched and found the Windows Installer XML (Wix), but it seems to be necessary to compile the entire project every time someone downloads. It's possible leave the program compiled and only add the configuration file after?
Apretiate any helps
Light (the linker in the WiX Toolset) has a feature called "cab cache" which will re-use the cabinet files which are embedded in the resultant MSI. You would use the arguments -reusecab and -cc to enable this.
You'll still have to re-build the MSI when the user submits your form, but the build will be faster (cabinet generation is usually the longest part of the build process).
I have formed a number of source code files as my library. For example, I wrote LinqExtension.cs providing Median() function.
Now I'm working on a project which needs LinqExtension.cs. As usually, I link the file to the project. As introduced here. The reason that I link files rather than copying them is to keep the files at a single location. If I modify a file, all dependent projects get affected.
I also add the project to Subversion and upload to and download from Google Code. The linked file is not under version control.
I work on the project at home as well as at office. I hate copying the linked file to my office, which makes the file not single.
I figure out a solution that add <Compile Include="http://www.example.com/LinqExtension.cs"/> to csproj file so that the file only exists on the Internet. Once I upload a new verison of the file, all dependent projects get affected. Unfortunately the solution doesn't work.
Any other suggesions or better practice?
A better way would be to share your core library at the binary level, rather than at source code. You could set up a private Nuget repository to make this easier.
If it is absolutely necessary to share files, you can use pre-build actions in your project to copy the file from a common location, or even download them from google code. It's not clean, but if you don't want to use source control for it then I don't think you will find a clean way.
I like to keep a library folder of binaries in my Dropbox. That way Common libraries that I use can be accessed from my home and work project workspaces and the service keeps the version up to date.
I want to ask about the main considerations we have to put in mind when publishing application using SQLServer database?
I ask this question because I faced a problem when I developed an application using SQL server Database in C# and used it in another machine. The problem is an exception happen in launching the application.
This is the exception message:
<b>"The ConnectionString proberty has not been initialized"</b>. The ConnectionString is in App.config and assing while form loading.
This is the ConnectionString:
<b>"Data Source=.\SQLEXPRESS;Initial Catalog=test;Integrated Security=True;Pooling=False"</b> and it is in this file: appName.exe.config
The application is Desktop application and it's not need for installation just click .exe and it should connect to the existing SQLServer database with the ConncetionString in the appName.exe.config file.
The best way to deploy any type of application will be creating a setup.exe or .msi file.
Since this will ensure the important files which will copy to the target machine. It also provides a well structured file hierarchy along custom action which we can program each and every steps of installation.
It is always good to keep the connection properties in a config file, which helps to change the configuration settings without building the project. The exe will reads data from the config file, so if we changed the values then also it will works fine. While creating the setup project add the configuration settings and deploy or it is also good to have a common setup msi and different config files.
For example the database may be different for servers like DEV,QA,Staging etc. For each sever the msi will be same but the connection string will be different. So there is also a way to create self extracting files which will update the config files . For QA,DEV,Staging etc different self extracting files will be there. by running those files, it is possible to update the server details and authentication details. By providing msi and extracting files, users can install the application very easily