SapphireSteel Forum
Welcome, Guest. Please login or register.
August 24, 2017, 04:25:00 AM

Login with username, password and session length
Search:     Advanced search
Welcome to the SapphireSteel forum - for discussion of the Sapphire and Amethyst IDEs
4074 Posts in 848 Topics by 708 Members
Latest Member: dcham_inbsys
* Home Help Search Login Register
+  SapphireSteel Forum
|-+  General
| |-+  Amethyst
| | |-+  Difference between Copy to Output Directory and Build Action ?
« previous next »
Pages: [1] Print
Author Topic: Difference between Copy to Output Directory and Build Action ?  (Read 22931 times)
digxstudios
Newbie
*
Posts: 20


« on: August 04, 2013, 08:31:28 PM »

I'm trying to clean the bin-debug folder of our converted project, i found a bunch of content, mostly images that we use, into it.

When i checked the properties of the file, i could see Copy to Output Directory being set to False, but its Build Action set to Content.

Seems to me like these 2 might be in conflict.

Its kind of unclear to me why having BUild Action of Content will override the Copy To Output Directory setting of false.

Am i misunderstanding their purpose ?
Logged
digxstudios
Newbie
*
Posts: 20


« Reply #1 on: August 04, 2013, 08:53:27 PM »

Actually, after looking close, i see a bunch of stuff that comes from the upper level at the same level as the src folder.

I don't recall flash builder doing such a thing, it would mainly process things under the src folder if i recall properly.

Now, i can see how beneficial that can be to a project and to help with a Deploy scenario, and i like it but i think that when someone converts a flash project, only things under the src folder should be set to content and the rest to None.

Also, when importing a project or flash workspace, i would strongly recommend that the "prefix / to Embeds" be set to off by default as this can be really disruptive on large project because it modifies the source code directly and could create confusion if, for example, i had a few set with a beginning "/" but others not. Remembering which were could become a challenge.
Logged
Dermot
Administrator
Hero Member
*****
Posts: 1068


« Reply #2 on: August 05, 2013, 05:33:36 AM »

Thanks for the suggestions.

The 'copy to output directory' is to make testing of the program easier. Often, the SWF refers to items which are relative to its disk location, and it's a lot easier to test and debug if these files are copied over automatically.

I can see why you would only want code under the main source folder to the Content or Compile. We will modify the importer.

We had the embed switch the other way round in previous versions of Amethyst. We will switch it back again.

Th embed business is peculiar. FB seems to 'fix up' these embeds on the fly, but the syntax is actually incorrect, as has been pointed out many times by people who try to do batch builds instead of using FB to do it. Adobe at one time promised to address this problem (the inconsistency between the command line compiler and the way FB handles Embed), but since they lost interest in FB and Flex, I suspect this isn't likely.

The Build 'actions' are as follows:

Code:
public enum BuildAction {
Compile,      // the file will be compiled
CompileCSS,   // the file will be compiled as a stylesheet
Content,      // the file will be copied to the output directory (can be overidden by 'CopyToOutputDirectory' = false)
Module,       // the file will be compiled as a module
None,         // the file will be ignored by MSBuild
Resource      // the file will be included as a resource using '<include-file>'
}

Dermot
Logged
digxstudios
Newbie
*
Posts: 20


« Reply #3 on: August 05, 2013, 09:02:29 AM »

We had the embed switch the other way round in previous versions of Amethyst. We will switch it back again.

Th embed business is peculiar. FB seems to 'fix up' these embeds on the fly, but the syntax is actually incorrect, as has been pointed out many times by people who try to do batch builds instead of using FB to do it. Adobe at one time promised to address this problem (the inconsistency between the command line compiler and the way FB handles Embed), but since they lost interest in FB and Flex, I suspect this isn't likely.

I don't recall if there was such an option, but maybe make the "/" to embeds a command, like in edit menu or such. But given the extra details you provided, I can see how this can be a gray area.

I'd like to mention another possible issue, but that's probably because we have our setup done in a weird kind of way.

Our project structure is something like this:
root
/flaProjects - contains CS5 projects to make our external/embedded swfs
/libs - Our flaProjects's swc files for embedded swfs
/sdks - Currently we have flex 3.6A sdk in there, this allows a new employee to be ready without having to download anything special, and also makes sure we all use the same one.
/src  - our sources, things to compile etc
/utils - things like TheMiner swf which allows to profile or something like that

So what I've realized is that when I load the solution, all files are parsed for auto-complete functionality, but it doesn't parse only under /src but all folders under root. I'm not sure if that is ever desirable since all refs should already be in the references section and source files should be under /src. but, what if we could exclude those root folders from IntelliSense parsing by having a "exclude from IntelliSense parsing", this could translate into an extra attribute or custom attribute of the folder entry in the amproj file like:

<Folder Include="flaProjects" ParseIntelliSense="False" />

Here's an example of what I get in my IntelliSense parsing errors output:

Warning: namespace not declared at 53 in D:\Src\Flash\UIMain\AllianceWarfare\sdks\3.6.0\frameworks\javascript\fabridge\samples\app.mxml
Background parse of 'D:\Src\Flash\UIMain\AllianceWarfare\sdks\3.6.0\frameworks\projects\airframework\src\mx\controls\FlexNativeMenu.as' requeued

Hoping I'm not too much of a pest with all these comments/suggestions.
Logged
Dermot
Administrator
Hero Member
*****
Posts: 1068


« Reply #4 on: August 05, 2013, 11:33:40 AM »

I like the idea of excluding entire directories ....

Code:
<Folder Include="flaProjects" ParseIntelliSense="False" />

that would work quite well. I think we'll do that - but I'll think about it for a day or so first to see if there are any downsides.

However, the structure you've got is not optimal. First, having the SDK in the same project really will slow things down from an IntelliSense point of view, because a full source level IntelliSense scan will populate the database will many, many things that you will never want to look at. It would be better to have the SDK as a referenced SWC. That way you will get the things you want like function names, etc. by without the overhead of a source scan. The IntelliSense scan of an SWC is fast and very efficient; a source scan of the thousands of files in the SDK will take a lot longer.

You can have many projects in an individual Visual Studio solution, so I would split out the SDK into a separate project and having built it, normally keep it unloaded but with the SWC referenced in the main project.

Ideally, each Visual Studio project should produce a single SWF or SWC and you can either reference the project library or the project's SWC. We have some examples of how to do this if you need any help.

The problem with the importer is that it has to be a very generic tool and has to be able to cope with all the structures that are out there - the result is sometimes not what you would start out with if you were starting with a clean sheet of paper.

No problem with the suggestions - very happy to have them if they lead to a better product. Many of our customer's suggestions have been incorporated!

Dermot

Logged
digxstudios
Newbie
*
Posts: 20


« Reply #5 on: August 05, 2013, 02:20:01 PM »

In our project, we're producing only the game client swf.

I add a reference to the included SDK and add references to the SDK's SWC libraries I pick to be referenced. So I don't need that SDK folder to be parsed and we don't modify it or anything, its just there for having a common base when a new employee comes in. That way we know he'll be ready to work within minutes of having things pulled from team server. I guess we could remove it from the visible path but this is our guarantee that all needed things will be pulled correctly.

Same applies for the flaProjects folder, these are CS5 projects that we already built SWC files for and we reference the SWC files from our main project. But having them there means that if one of the employee needs to adjust something it can be done without looking too far.

So, technically speaking, these would be the first 2 folders I would put intellisense parsing exclusion on, and even build exclusion on (for build exclusion I've set all the entries in the project file to None instead of Content or Compile.

I'm not sure how other projects would go about this, probably not the way we did it. But this worked well with flash builder, which is why we did it the way it is. I'm currently discussing with my flash coder to see if we could go a different way about these, but still think there might be situations where manually excluding a folder from build or intellisense would make sense.

Thanks you for taking my input into consideration, really appreciate it.
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!