On a clojurescript project, I've needed to access contrib/externs/w3c_audio.cljs
I thought if I just wrote it in, google would access it, but I couldn't get that to work. Instead, I went in and just copied the file to my local directory.
Is there a way to not do that? i.e write something in my project.clj that knows I want to get the file in closure-compiler's contrib/externs?
:externs ["react/externs/react.js"
"externs/custom.js"
"node_modules/jquery/dist/jquery.min.js"
"contrib/externs/w3c_audio.js"
]
If your project doesn't use any other Clojurescript libraries that requires extra extern files, consider using fence.core/.. for javascript interop:
https://github.com/myguidingstar/fence
Even if your project does, fence still helps reduce number of extern files to work on
Related
I want to create a file called config.js for the client end of my app, but it should be based on the environment. I've successfully done this for production using the tasks/register/prod.js file, but sailsjs does not seem to have an equivalent dev.js file.
I also can't find much information about this, so I'm hoping there is a standard workaround I'm just not thinking of.
I'm not sure why I found it so confusing, or why I never opened the README.md (duh!) in tasks/, but dev stuff goes in the default task (tasks/register/default.js).
ANSWER: README's are named as such for a very good reason.
I usually follow the unofficial Meteor FAQ on how to structure my codebase, but I can't figure out where I should put my global constants.
To give an example: I have some database entries with a constant GUID that I need to reference in many points of my app. So far I just attached the constants to the relevant collection, such that in collections/myCollectionWithGuids.coffee it would say:
#MyCollectionWithGuids = new Meteor.Collection "myCollectionWithGuids"
#MyCollectionWithGuids.CONSTANT_ID = "8e7c2fe3-6644-42ea-b114-df8c5211b842"
This approach worked fine, until I need to use it in the following snippet, located in client/views/myCollectionWithGuidsView.coffee, where it says:
Session.setDefault "selectedOption", MyCollectionWithGuids.CONSTANT_ID
...which is unavailable because the file is being loaded before the Collections are created.
So where should I put my constants then, such that they are always loaded first without hacking in a bunch of subdirectories?
You could rely on the fact that a directory names lib is always treated first when it comes to load order.
So I would probably advise you to organize your code as follow :
lib/collections/collection.js
client/views/view.js
In your particular use case this is going to be okay, but you might find cases when you have to use lib in your client directory as well and as the load order rules stack (subdirectories being loaded first), it will be loaded BEFORE the lib folder residing in your project root.
For the moment, the only way to have full control over the load order is to rely on the package API, so you would have to make your piece of code a local package of your app (living in the packages directory of your project root).
It makes sense because you seem to have a collection and a view somehow related, plus splicing your project into a bunch of collaborative local packages tends to be an elegant design pattern after all.
Creating a local package is really easy now that Meteor 0.9 provide documentation for the package.js API.
http://docs.meteor.com/#packagejs
I would put your collection definitions in a lib directory. File structure documentation explains that all files under the lib directory get loaded before any other files, which means your variable would be defined when you attempt to access it in your client-side code.
Generally speaking, you always want your collections to be defined before anything else in your application is loaded or executed, since your application will most likely heavily depend upon the use of the collection's cursor.
A web service client (WCF) is compiled as a DLL, then comes the dll into the folder "c:\windows\assembly" ... just like I can now say that my DLL in C:\client\client.dll.config is expected?
It would perhaps also the possibility that the program store directly, the problem is that it starts from a SharePoint workflow that is surely not quite that simple.
It may sound silly, but the problem sounds so simple ... Unfortunately I have found so far after a while no concrete solution to Find.
EDIT:
No idea? It is the despair, I am running out of time and I have so much work to implement all this, and such a ridiculous number of hours to keep me?
I've found a lot in terms of editing files, but I will not change it I will change only the access to another directory where the file is ...
In the proxy classes, we refer only so eager ...
[System.ServiceModel.ServiceContractAttribute
(Name = "_-ASD_-CAS01D0005P0000013203",
Namespace = "urn:sap-com:document:sap:soap:functions:mc-style",
ConfigurationName = "_ASD_CAS01D0005P000001320")
]
There must theoretically be possible to simply change the ...
I'm just trying to throw it somewhere in the folder of SharePoint, there is the program being started. The file is from "C:\Windows\system32\inetsrv" started, but on this directory, the dll probably does not have access, because I still get the same error as if there was no config file there.
The file is from "C:\Windows\system32\inetsrv" started, but on this directory, the dll probably does not have access, because I still get the same error as if there was no config file there.
Finally solved by
AppDomain.CurrentDomain.GetData ("APP_CONFIG_FILE");
I can not find it an addictive client.dll.config, but instead the web.config in SharePoint virtual directory "c:\inetpub\wwwroot\wss\Virtual Directories\80\" searches. I added the information there and it works fine!
in my project, I want to refer to an other xcconfig file, located in InDesign SDK. As this SDK may be installed at different locations, depending upon the machine, I prefer to declare an environment variable for locating it.
Nest step is obviously to use variable (aptly named ID_CS5_SDK_DIR) in my xcconfig include directive.
Unfortunatly, when I try the simple
// InDesign sdk project build settings (based on common build settings)
#include "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
XCode throws me a
[WARN]AutocatPlugin.xcconfig line 7: Unable to find included file "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
How can I make it work ?
I've been trying to do this too and also came to the conclusion that it is not possible.
I once tried to achieve that and came to the conclusion that you can't. I would be happy if someone proves us it's possible though then delete my answer
It seems like .xcconfig files can only DEFINE and set value to environment variables (which prevail only throughout the build session) but not USE or evaluate environment variables.
Maybe it is because .xcconfig files serve as a base layer of build-settings, and are not parsed.
Unfortunately this is not possible, but instead of making one include the other, you can use two different xcconfig files per target. Just select one for the Project and one for the Target.
If you put the environment variable in /etc/config/launchd.conf and then reboot it will be accessible to the .xcconfig file.
Short Instructions for experienced users:
Edit the read-only file /etc/launchd.conf and add 'setenv VARIABLENAME /FOLDER/PATH' to the file, then reboot.
Steps For Inexperienced Users
Open Application/Utilities/Terminal, and entersudo nano /etc/launchd.conf
Create the Environment Variable by adding a line like setenv VARIABLENAME FOLDER/PATH and then pressing ENTER.
Save the file using Ctrl-O, Ctrl-M, (Possibly Ctrl-Y to overwrite), then Ctrl-X to exit the editor.
(Optional) type cat /etc/launchd.conf to see that your changes are present
Restart your computer. (Logoff doesn't work)
You can now access the variable in your .xcconfig file as$(VARIABLENAME)
Notes:
This creates a GLOBAL environment variable, accessible to all users. It probably doesn't make sense to set this to something in your home directory (e.g ~/MyFolder). If you do this, however, you need to use the full pathname, such as /Users/MyUserName/MyFolder).
References:
Stack Overflow - Setting Environment Variables in OSX
Stack Overflow - Are there any differences between /etc and /private /etc
Simple task, but for some reason no simple solution just yet.
We've all got web.config files - and I haven't worked anywhere yet that doesn't have the problem where someone yells across the room "Sh*t, I've just uploaded the wrong web.config file".
Is there a simple way of being able to auto generate a web.config file that will contain the right things for copying to release? An example of these being:
Swap connection string over to use live database
Change
Switch over to use the live/release logging system, and live/release security settings
(in our case we need to change the SessionState mode to InProc from StateServer - this isn't normal)
If you have others, let me know and I'll update it here so it's easy for someone else to find
Maintaining 2 config files works, but is a royal pain, and is usually the reason something's gone wrong while you're pushing things live.
Visual Studio 2010 supports something like this. Check it out here.
How are you deploying your builds. In my environment, this used to be a pain point too, but now we use cruisecontrol.net and script our builds in nant. In our script, we detect the environment and have different versions of the config settings for each environment. See: http://www.mattwrock.com/post/2009/10/22/The-Perfect-Build-Part-3-Continuous-Integration-with-CruiseControlnet-and-NANT-for-Visual-Studio-Projects.aspx for my blogpost onthe subject of using cruisecontrol.net for build management. Skip to the end fora brief description of how we handle config versions.
In my most recent project I wrote a PowerShell script which loaded the web.config file, modified the necessary XML elements, and saved the file back out again. A bit like this:
param($mode, $src)
$ErrorActionPreference = "stop"
$config = [xml](Get-Content $src)
if ($mode -eq "Production")
{
$config.SelectSingleNode("/configuration/system.web/compilation").SetAttribute("debug", "false")
$config.SelectSingleNode("/configuration/system.web/customErrors").SetAttribute("mode", "off")
$config.SelectSingleNode("/configuration/system.net/mailSettings/smtp/network").SetAttribute("host", "live.mail.server")
$config.SelectSingleNode("/configuration/connectionStrings/add[#name='myConnectionString']").SetAttribute("connectionString", "Server=SQL; Database=Live")
}
elseif ($mode -eq "Testing")
{
# etc.
}
$config.Save($src)
This script overwrites the input file with the modifications, but it should be easy to modify it to save to a different file if needed. I have a build script that uses web deployment projects to build the web app, outputting the binaries minus the source code to a different folder - then the build script runs this script to rewrite web.config. The result is a folder containing all the files ready to be placed on the production server.
XSLT can be used to produce parameterized xml files. Web.config being xml file this approach works.
You can have one .xslt file(having xpath expressions).
Then there can be different xml files like
1. debug.config.xml
2. staging.config.xml
3. release.config.xml
Then in the postbuild event or using some msbuild tasks the xslt can be combined with appropriate xml files to having different web.config.
Sample debug.config.xml file can be
<Application.config>
<DatabaseServer></DatabaseServerName>
<ServiceIP></ServiceIP>
</Application.config>
.xslt can have xpaths referring to the xml given above.
Can have a look at the XSLT transformation This code can be used in some MSBuild tasks or nant tasks and different web.config's can be produced depending on the input config xml files.
This way you just have to manage the xml files.
There is only one overhead that the xslt file which is similar to web.config need to be managed. i.e whenever there is any tag getting added in the web.config the xslt also needs to be changed.
I don't think you can 100% avoid this.
The last years of work ever and ever shows: where human worked, there are fails.
So, here are 3 ideas from my last company, not the best maybe, but better then nothing:
Write an batch file or an C#.Net Application that change your web.config on a doubleclick
Write a "ToDo on Release"-List
Do pair-realesing (== pair programming while realease :))