We have our class libraries on a shared server we access via Samba (and ssh for command line). Sadly, several features seem to fail in both Flex Builder and Flash Builder/Gumbo with this setup. For example, we no longer get automatic syntax and error checking. Anyone familiar with this issue and able to suggest a solution? Thanks!
Turns out this problem had nothing to do with our abstruse setup. I had simply forgotten to create a reference to the top-level class in the application file (bear in mind that with this setup the Flex project folder exists only to satisfy FB's need to place project files somewhere...all the real code is off on the server). Once this was done, all normal services were restored.
Related
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
So i have had no luck piecing together the documentation on how to do this as it seems a bit scattered.
So i have a dedicated box running TCadmin. I have a cs go server deployed through it however now i have reached the stage of needing to add my GSLT.
I have looked through all the documentation and i have kind of got to the point of realising that i need to edit the default template of configuration that is used so that i can add a autoexec.cfg and allow that to be edited through the config editor. The other way would be to edit the default command line to allow +sv_setsteamaccount
I am totally stuck as to do either of these things though.
Any advice appreciated.
Contrary to nearly every other source on the internet, i CAN declare the login token in the server.cfg
The problem i was facing with the templating turned out to be simply a misunderstanding of the fact that the linux template was set up as a kind of "child" of the windows version as all the configs are the same. I had to amend the windows setup.
Is there a possibility to use a local application.conf with Play 1.2.5? Our problem is that different developers have somewhat different setups that we don't want to save to version control.
Alternatives found:
Just modifying application.conf
Have to be careful not to commit changes to VCS
Environments : Own environment for each developer : %john, %mary (saved to VCS)
OK alternative, even though we woudn't like to save those to version control
We have do change those during development every now and then -> would cause unnecessary changes
#include : application.conf option for additional configuration files
Play 1.2.5 documentation : This is an experimental feature that does not yet work properly. :(
Something else?
Especially, is there a way to tell Play to use custom file name (as "conf/application.conf.local" instead of default "conf/application.conf"?
You can append:
%my_play_id.#include.application.conf=my_application.conf
At the end of application.conf. One line per developer or environment. You can override some properties in my_application.conf and is not necesary to prepend %my_play_id to the properties changed. For example if you have three developers:
%developer1.#include.application.conf=developer1_conf.conf
%developer2.#include.application.conf=developer2_conf.conf
%developer3.#include.application.conf=developer3_conf.conf
I have looked at the Play! 1.2.5 source code, but find nothing that suggests that Play! would be able to pick up anything other than the file conf/application.conf.
I just encountered Play 1.x module externalconfig that could help. Seems to work for our purposes. As an extra, this helps to keep production passwords etc out from the VCS.
Note that this module works only within Play's Java code - Play modules implemented in Python (as migrate, for example) won't be aware of external configuration. There might be concerns also with other Java modules that rely on onConfigurationRead().
#include have worked for our setup where we import different environment configurations on play 1.2.5.
If your team is small, have each dev check in their own config each with their own prefixed user-key:
%[user-key].[property]=[value]
each developer will then have to change starting up play with
play run --%[user-key] instead of simply play run
What we do is create a application.template configuration for the VCS that has the recomended configuration (instead of the actual application.conf).
This way every developer is responsible to create their own application.conf and to improve the template in the VCS.
This way no one mess with the deploy configuration and the configuration of the other developers.
If you want to version control the deployment configuration just add this to the tagged versions of your VCS
I currently use RoleEnvironment.GetConfigurationSettingValue(propertyName) to get the value of a setting defined in my WebRole config file (csdef + cscfg). Ok, sounds right.
This works well if the setting exists but failed with an Exception if the setting is not defined in the csdef and the cscfg.
I'm migrating an existing app to Azure which has many configuration settings in web.config. In my code, to read a setting value, I d'like to test : if it exists in the webRole config (csdef + cscfg) I read it from here, otherwise I read it with ConfigurationManager from web.config.
This would prevent to migrate all settings from my web.config and allow to custom one when the app is already deployed.
Is there a way to do this ?
I don't want to encapsulate the GetConfigurationSettingValue in a try/catch (and read from web.config if I enter the catch) because it's really an ugly way (and mostly it's not performance effective !).
Thanks !
Update for 1.7 Azure SDK.
The CloudConfigurationManager class has been introduced. The allows for a single GetSetting call to look in your cscfg first and then fall back to web.config if the key is not found.
http://msdn.microsoft.com/en-us/LIBRARY/jj157248
Pre 1.7 SDK
Simple answer is no. (That I know of)
The more interesting topic is to consider configuration as a dependency. I have found it to be beneficial to treat configuration settings as a dependency so that the backing implementation can be changed over time. That implementation may be a fake for testing or something more complex like switching from .config/.cscfg to a database implementation for multi-tennent solutions.
Given this configuration wrapper you can write that TryGetSetting as internal method for whatever your source of configuration options are. When this feature is added to the RoleEnvironment members, you would only have to change that internal implementation.
I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.
Unfortunately, that doesn't work.
The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.
I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?
If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)
there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.
To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.
Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.
For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
For reference, I am the primary author of FireBreath and I wrote the article.
I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".
EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.
I see 3 options:
Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.
Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.
If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.
What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.
EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.