I have an application lets say "Application1" .I want to install same application but by changing some contents in it and also its name like "Application2" so that both application1 and application2 can be seen on device?
Is this possible?If yes,then can someone kindly help as to how to do it.
EDIT:
Just if somebody else might need it, I got this done.
Get a GUID from a GUID generator tool and use this new GUID in WMAppManifest.xml and replace ProductId in this file and GUID in AssemblyInfo.cs.Rebilud the solution and its done!
Creating a new app with exactly the same content is very easy:
Create a new project and name it with the new name.
Remove the pages/classes created by default in the new project.
"Add as Links" all the pages/classes from the original project.
If you want to have different content in the second app, just put the different content in a separate file and use that rather than a linked one. (Partial classes split across multiple files make this very easy.)
Another way to customize content in the second app is to define a partial method in the original app but only implement this in the second app (in a partial class/file which only exists in the second app). In the implemented partial method add your changes to override the default (original app) behaviour/layout/whatever. - This is a good way of altering pages where you don't want to have to put customization into an already existing app. You just "override" it in the second app.
You would need to submit the two slightly different applications to the market as separate applications in order for them to be seen on the user's device.
As Matt suggests, if the two applications have a lot in common, then you can use linked files to reduce your maintenance overhead.
In addition to Matt's suggestion, I've done this for Free/Paid versions of the same app.
It's pretty easy to do. The files to change between versions are:
the icons
the splash screen
the mobile XML file in the Properties folder
The important thing in the XML file is the GUID identifying your app. This GUID doesn't seem to be used in the Marketplace - but it is used by the debugger's deployment functionality.
You can also use a project level #define to include/remove any other code you want different between the projects.
Related
I have created three projects on Visual Studio. One is the base project and I would like to embed the other two projects into the base project. I went through some articles but couldn't find something that suits my requirements (and I am still a newbie in asp.net :)). Below is a screenshot of what I created
I will like to call FirstApp and SecondApp when I run the BaseApp and also display some unique texts like "hello from FirstApp" and "hello from SecondApp".
All you need to do is create a reference to the projects you want to use, and then call the code in those projects.
You can add a reference to another project by right clicking BaseApp, select Add, and Reference. Then you get a screen where you can select the other projects in your solution. Select the ones you want to use, and you can start to use the classes in the other projects.
If you want to use FirstApp and SecondApp then create class library of those project and add those library reference in your first project [base].
After that you will get all method access in this project based on assembly type.
If what you want is to see on a page loaded from a web application another page loaded from a different web application, then you need to use iframes.
To do this you do not need even if the projects are in the same solution. They are different processes. They could even be in different domains. You are really using the http protocol to create the iframes. The applications are completely isolated.
I'm creating a new VS2015 web application, but there's one piece that requires some reporting that already exists in another system.
The other system is a VS2013 solution that has a website (not web application) as it's main project, along with a number of class libraries. But the website directly contains a bunch of classes that do reporting and other things, and I would rather use those than recreate all the (very complicated) code.
Is there any way to reference the classes in the website from another project or class library? It's a rather large old application I'm maintaining, and I'd rather not try extracting all that functionality into it's own class library if I don't have to.
If those classes were already in a separate class library, I could reference them easy enough, but unfortunately they are right in the website, and I can't find any information about being able to link to it (presumably because you can't).
Here's a sample structure:
MySolution
MyNewClassLibrary
MyClass
{
MyReportFunction()
{
var x = new ReportClass(); // From website project
x.CreateReportFunction();
}
}
OldSolution
WebsiteProject
ReportClass
{
CreateReportFunction()
{
// All the code I'd like to access
]
}
Is this possible? Or do I have a lot of rewriting to do? Or would looking into converting the website into a web application be a better idea?
You can add those existing classes as linked classes into your solution.
To add an existing item to a project
In Solution Explorer, select a target project.
On the Project menu, select Add Existing Item.
In the Add Existing Item dialog box, locate and select the project item you want to add.
From the Open button drop-down list, select Add As Link.
You can also read more details here.
In case anybody else is looking for something like this, the answer is no, it's not possible.
I ended up pulling all the functionality out into a new class library project, which required massive testing to make sure I got all the little bits and pieces right.
Moral of the story - build your software properly the first time, and pull functionality out into reusable objects. Don't do procedural programming in an object-oriented language.
We have a sharepoint doucment library, the site consist media files(like images, word document, .psd file) and then we have a local CME (Alterian) which can be integrated to the SharePoint library in order to share the document library but the site needs to be on http// not an https//, coincidentally current sharepoint site is on https//, so we need to figure out a way/write a module which will work as a scheduled job (possibly using SPJobDefination class) and check on https// site for recently modified/added or deleted documents/records and then will copy them/normalize them to a dev site (hosted on http//, replica of the production https// site).
Experts please share your view's to proceed with a best approach to make this happen. (At an initial stage I'll have to copy over all the existing meta-data from the current https// site aswell)
Thanks a lot in advance for the time.
I would use event handlers on the https document library. Please see the SPItemEventReceiver.ItemAdded Method and SPItemEventReceiver.ItemUpdated Method.
So, every time you will add or modify an item, the code inside the methods is triggered. Inside the code, you may take the library document and copy it to the http site.
Regarding the existing items, you could write a simple console application which will copy the items from one list to the other.
Make sure that you make use of the SPListItem.SystemUpdate Method.
Also, the following excerpt from an answer to the question Moving Documents from library to library deletes version history, how do you retain it? could be helpful for starting:
(...) We can get the “SPFile” and the “SPFileVersion” objects from the
original library and add them to another library one by one. After
copying a file or version, get the original custom property form the
source file or version and use the “SPListItem.SystemUpdate(false)”
method to update the target file or version. This workaround can
persist most of the properties except the “modified time” or “modified
by” field. (...)
I have a multi-language windows application that uses standard .net localization in resx files.
Now I have a request to add a possibility for user to create his own language files that are not originally supported and add them to the application without recompiling it.
What's the best approach to achieve this?
I'm considering moving the languages to database and then crating a second tool that'll add translations to the database, but would rather keep the current approach, if it's possible to add resx files dynamically.
This is exactly why I don’t use .NET localization but wrote my own.
I store the translations in files separate from the EXE, have a Windows-Forms-based GUI for translation that I can embed in any application (and working on a WPF clone of it), and allow users to switch languages without restarting the application.
I don’t get why anyone would want it any different and why Microsoft created such a bad and limited system.
Unfortunately, I cannot publish my system right now, but I’m hoping I’ll be able to soon.
One option you can use is keep the translations in an XML file. This way, the user can just drop his own XML file into the folder where the translation exists.
You could write the translations to .resx file and just add the location of that file to the database and then when you want to translate some label just go to the database to see where that file is and then read from it. I'm not sure though how it would fit with a localisation lib...
I have thought of three approaches to create and maintain resources in .Net projects for WinForms using Visual Studio 2008. (I am sure there should be more than three ways.) I need to decide on one before starting to implement internationalization for our product.
Have individual sets of resource files (resx) for each windows form or piece of UI (a custom control) in each .net project. These are auto generated by Visual Studio when Localizable property is set to true in the form or control properties.
Have one resource file per .net project. This is added manually and updated manually with the resource strings and messages.
Have one resource manager project that has resources for all the components for a set of .net projects.
Personally, I do not like the first approach as it creates numerous resources files. The only advantage we get in this approach is that we do not need to set text in UI elements manually.
I like second and third approach as they are easy to maintain and there is only one set of resources that you need to handle. So no duplication of strings and messages. Easy for the translators also.
What are your thoughts? Please share.
I have tended to use VS to create the project and provide the default set of resources but then maintain any additional resources outside of visual studio via the SDK tools winres.exe, resgen.exe and al.exe.
You can maintain the resources in a fairly simple folder structure of one folder per culture and just have a batch file or two to build the resources into satellite assemblies. This gives you the advantage of keeping the VS solution to the core product and all localisation can be done after the fact.
If internationalizing your app means more than translating pieces of text you should go with the first one. You can create satellite assemblies to deploy different cultures. This way you are not localizing just text but also images, control layout, etc. This is the way how Microsoft recommends it and they have good reasons for taking this approach.
I've found that the simplest approach to internationalization is to simply maintain a list of all the different pieces of text in your application (labels, buttons, form captions etc.) in a spreadsheet or tab-delimited file of some sort, and then send this file to the translators to add (in one additional column for each language) all the translations.
You then call a simple method in the Load event of each form (which are all maintained in English) that iterates through all the controls on the form recursively and changes their Text properties to the translated values for whichever language you're translating the app into. The language can either be determined programatically (I forget where in the .Net namespace this is indicated), or you can have a simple language selection dialog when the application first starts (the advantage of this second method is that your app can be translated into whatever language the user wishes, without having to set the language for all of Windows - this is especially useful for kiosk applications).
In my opinion, creating and maintaining all the different internationalized versions of every form is a major pain, although it is useful when the translated text values are significantly different in size from the English versions.
Personally, I prefer the first approach because the context (in your case, the forms) is very important for a translator to do his job perfectly. In your second and third approach, the context is gone because it is just a list of strings.
Yes, the first approach can be a pain to maintain but at least your application would be translated correclty.
I personally love to add a single project .Resources.
Next I enable Microsoft MAT ( https://developer.microsoft.com/en-us/windows/develop/multilingual-app-toolkit ) and manage all my translations via MAT.
This way you can also recycle translations from other solutions, saves you time ;-)