My compact framework application is generating a ...asmmeta.dll file in the output folder. What exactly are these files and why are they created? I have made compact framework applications in the past and it hasn't created any files like this.
One possible reason (you've not said a lot about what you're building) may be that you have USerControls or custom controls of some sort. In that case, the asmeta files are created for Studio designer support of those controls. Do you also have an XMTA file in the project?
Related
I'm creating a RN app that is meant to be some kind of wrapper. It should have multiple targets (like in Xcode) and all its content (images, text, etc.) should be target dependent. Unfortunately, I cannot find any useful informations about how to achieve this without opening Xcode or Android Studio project and create those targets manually (like here). Is there any other solutions for this?
I was still struggling with described problem but I finally found a solution. It's not easy, needs writing a bit of boilerplate code and looks more like a workaround but I hope it will help someone in the future. What I did is I have completed my wrapper app with the resources for one of my targets so I can have visual effect. In the project's root directory I've created a folder with subfolders for each target. Inside each I have put files (images, source code files, other assets) that are target-dependent. Then I've created bash script that takes one argument - target's name. Based on it, it replaces all the target-dependent files from target's subfolder to the original file's destination in the project structure. In this proces all meta-data informations are also replaced so after firing .sh file I can build the app and upload it to both stores. It's really time consuming to create all these apps separately and publish them and it's maybe not the best solution, but at least it works!
On android, you can edit build.gradle files, java or properties, without having to launch Android Studio (which simply uses Gradle)
You can build different type flavours by only changing app/build.gradle
On iOS, that's another story. Project file (.pbxproj) is a mess,and other Workspace/Scheme files are not easy to read or script. So XCode is the way to Go.
I tried to have dynamic target & Info.plist, there are tools to script that like PlistBuddy
in the end, I saw there are many ways to launch a React Native app for developpers. Some prefer the command line, and only VSCode.
Others want to play with native IDE.
By the way, native IDEs are VERY useful.
e.g. : you want to fine-tune your application performance, using XCode view hierarchy debugger or android Studio Layout Inspector (and be sure you don't use to many views), or use any other performance tools these IDEs offer...
In the end, I used react-native-config along with multiple almost similar configs (Info.plist < target < Scheme for each), here's a post giving an overview of the setup.
I am building a web project in Visual Studio that uses dojo, but I am unsure of how to link in the 3rd party dojo files so they get copied to the output directory.
In the past for things like jQuery, I placed the jquery.js file in a separate folder, went to "Add Existing Item," added jquery.js as a link, and set Visual Studio to copy it to the output directory (if newer). This worked great.
For dojo, there are hundreds (if not thousands) of related external files. This is not practical to add to Visual Studio (though I did find a way to do it in bulk).
This makes me think that I am approaching this incorrectly. How can or should I include something like dojo in a C# project without having to reference each file? Should I use a post-build step to robocopy the files into the output directory?
My goal is to be able to build multiple projects which all use dojo, but I don't want to have multiple copies of dojo checked in, or have to reference each file in the project.
Use the "Add as link" feature of Visual Studio.
http://msdn.microsoft.com/en-us/library/vstudio/9f4t9t92(v=vs.100).aspx
. . .
I am also a Dojo user. You will want to learn to do Dojo builds, to reduce Dojo to just a few files, and host them on your server. In many cases, in lieu of that, with some tiny loss of efficiency for the first load (after that, caching takes care of things) using the one of the CDNs like google to access the Dojo files is also effective.
Depending on your particular circumstances, it may be better to put the files out on a server, and just reference them in your HTML templates. This is, for example, how we do all our internal Dojo applications in my organization--three developers use one set of Dojo files for all applications.
I have some resources (images in this case) in a resource file that I use on controls in my Windows Forms project. The Visual Studio Resource Selection dialog doesn't have very good support for choosing images from resource files unless they're in specific locations, but you can edit the designer file directly, and this works just fine; the application compiles and runs correctly, and the Windows Forms Designer is smart enough to not mess up my hand-edited code.
// in an assembly named ResourceConsumer
this.button1.Image = global::ResourceConsumer.Properties.Resources.Close32x32;
Now I want to move those resources to an external assembly so they can be used by multiple applications. I can set up an assembly to expose its resources without a problem (as long as I'm using Visual Studio 2008 or later), and this works fine. When I change the designer code to reference the image from its new location, the code compiles and runs correctly, but now the Windows Forms Designer changes my code whenever it generates code; it embeds the binary of the image in the local resource file and references it from there.
// ResourceProducer is an external assembly containing resources
this.button1.Image = global::ResourceProducer.Properties.Resources.Exit32x32;
is changed by the Windows Forms Designer to:
this.button1.Image = ((System.Drawing.Image)(resources.GetObject("button1.Image")));
The Windows Forms Designer seems to understand pulling a resource from within the same assembly, but not an external one. Is there any way to have the Windows Forms Designer allow me to use a resource from an external assembly?
I have the exact same problem and there may be an alternative approach, depending on your code-base. If the properties that have been modified to reference a specific resource are on custom controls, then you could add the [[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] attribute to those properties (override or hide them, if necessary) and the Designer will leave them alone.
However, if the properties are on basic UI elements (e.g. Form.BackgroundImage) then you'd have to have to override or hide those as well and I'm not sure how desirable that is.
Nope, the designer doesn't support this. Important that it works the way it does, localization through satellite assemblies wouldn't work otherwise.
You can do this but you have to write the code yourself. Pretty much what you find in the Resources.Designer.cs file. Do consider if this is worth the effort, it isn't very maintainable and sharing resource assemblies isn't much of an optimization. A terabyte disk is less than a hundred bucks.
Btw: never edit the Resources.Designer.cs file yourself.
Being new to VS, how may I think of these two concepts, what is the difference?
I find some missing information in the other answers (at least for people who come from other IDEs like, say, Eclipse) . To say that a solution is a container for projects is only part of the thing. The conceptual feature of a VS project (what determines its 'granularity') is that one project produces one output: typically an executable or a library (dll). So, if you are going to code three executables that uses related code, you'll create one solution and at least three projects - probably more.
A solution is a container for projects, and tracks dependencies between projects.
Just to come up with a metaphor..
A solution is like a house, a project like a room. Each room provides a piece of functionality whereas the house, a container of rooms, provides the means to link the rooms together and organize them appropriately.
Kind of corny but I made it up on the fly, so bear with me :)
It doesn't help that Visual Studio seems to make things more confusing. "New Project" actually creates a new SOLUTION containing a project. "Open Project" actually opens a solution containing one (or many) project. (The file menu says "Open Project/Solution" but it really is opening solutions. There is no "Close Project" only "Close Solution" which is accurate.
So, in VS you are always working within a solution. Many solutions contain only one project and newer developers are likely to think of them as the same thing. However you can add other projects into a solution.
In case anyone decides to scroll down this far... I thought the MS docs did a pretty good job at describing the differences. I've copy pasted (and rephrased) the relevant bits here:
When you create an app, application, website, Web App, script, plug-in, etc in Visual Studio, you start with a project. In a logical sense, a project contains of all the source code files, icons, images, data files and anything else that will be compiled into an executable program or web site, or else is needed in order to perform the compilation. A project also contains all the compiler settings and other configuration files that might be needed by various services or components that your program will communicate with.
You don't have to use solutions or projects if you don't want to. You can simply open the files in Visual Studio and start editing your code.
In a literal sense, a project is an XML file (.vbproj, .csproj, .vcxproj) that defines a virtual folder hierarchy along with paths to all the items it "contains" and all the build settings.
In Visual Studio, the project file is used by Solution Explorer to display the project contents and settings. When you compile your project, the MSBuild engine consumes the project file to create the executable. You can also customize projects to product other kinds of output.
A project is contained, in a logical sense and in the file system, within a solution, which may contain one or more projects, along with build information, Visual Studio window settings, and any miscellaneous files that aren't associated with any project. In a literal sense, the solution is a text file with its own unique format; it is generally not intended to be edited by hand.
A solution has an associated .suo file that stores settings, preferences and configuration information for each user that has worked on the project.
A Solution can have many Projects.
The Solution can also handle managing the dependencies between its different Projects...making sure that each Project gets Built in the appropriate order for the final Solution to work.
A project contains executable and library files that make up an application or component of an application.
A solution is a placeholder for logically related projects that make up an application. For example, you could have separate projects for your application's GUI, database access layer, and so on. The projects would be specific divisions for your program's functionality, and the solution would be the umbrella unifying all of them under one application.
A solution is a readable text file whose extension is .sln and having a structured content that describes the projects that it contains. A project is a readable XML formatted text file whose extension is .vcxproj and having a structured content according to its XML schema, and whose primary purpose is to contain the listing of source codes filenames and their dependencies or references to other project's source codes as well.
Solutions are containers for projects - you can also use them to organize items that are used across different related project (shared dll's and such).
Solutions are containers used by Visual Studio to organize one or more related projects. When you open a solution in Visual Studio, it will automatically load all the projects it contains.
When you create a new project in Visual Studio, it automatically creates a solution to house the project if there's not a solution already open.
You can set dependencies of projects on other projects in the solution. The dependent project is build after the project it is depending on is built.
For more details refer - https://learn.microsoft.com/en-us/visualstudio/ide/quickstart-projects-solutions
If you are from an Eclipse background you would probably go to build path of a project and add a dependency on other project or add an external jar. In VS you can do that in a single container called solution where all related projects are grouped together.
Eg. Let's say you are build and android and iOS app in xamrin, there would be some common code and resources that could go in a separate project and then your android and iOS projects can depend on this common code project. Also you could have projects to test these projects etc.
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!