Imaginons que j'ai déjà un ensemble de bâtiment de projet .NET 3.5 Assembly. Maintenant, je veux construire cette assemblée pour Silverlight, et de plus, maintenir sa version Silverlight avec des efforts minimaux.
Donc, essentiellement, j'aimerais conserver un seul projet, mais cibler deux cadres. Je ne veux pas conserver deux projets distincts, car cela pourrait conduire à des erreurs comme oublier d'inclure un nouveau fichier. S'il y a beaucoup de projets et de grande équipe, il est vraiment important d'exclure de telles erreurs.
Si cela est complètement impossible, toute solution fournissant des avantages similaires est acceptable.
5 Réponses :
Vous devez avoir deux projets car les références MSCORLIB sont différentes pour les deux plates-formes.
Consultez cette question: http : //www.google.ca/search? hl = fr & q = ciblage + Silverlight + et + WPF & META = & AQ = F & OQ =
Si tout ce que vous voulez faire, il y a une vieille bibliothèque .Net ordinaire qui partageait entre les deux, puis je suggère de créer deux projets (un pour Silverlight, un pour les mêmes fichiers) et comprenant les mêmes fichiers dans les deux projets. C'est beaucoup plus facile à comprendre pour d'autres développeurs.
Puis-je désactiver \ Activer les options nécessaires E.G. avec condition = "'$ (silverlightbuild)'! = ''"?
Vous pouvez si vous voulez. Mais vous n'aurez pas à être incorporé dans les deux fichiers de projet. par exemple. Chaque .Csproj #defines SL ou WPF ou Net35. Chaque CSPROJ comprend / exclut selon les besoins des fichiers / Libs. Ne liez pas non plus de fichiers, placez le CSPROJ dans le même dir et simplement "Ajouter -> élément existant".
Concernant "Puis-je désactiver" - je veux dire "Puis-je maintenir un seul projet à l'aide de la condition Msbuild Atribute?"
Je suis d'accord avec Scott. Sauvez-vous beaucoup de douleur. Deux projets qui partagent le même codeBase sont la voie à suivre. Vous aurez besoin d'utiliser VStudio dans les deux environnements, d'utiliser différentes libs, d'inclure / d'exclusion de fichiers, de faire autant de choses ... Facilement!
La raison pour laquelle il faut avoir deux projets
Avez-vous également exclu un lien avec les fichiers à l'intérieur de votre projet à partir d'un projet Silverlight? C'est une approche assez courante du partage d'une mise en œuvre entre Silverlight et le CLR complet. http://silverlight.net/blogs/justinangel/archive/2008/12/29/Unuant-silverlight-dlls-on-the-desktop. ASPX
Existe-t-il un outil permettant de maintenir le projet original du projet et Silverlight avec des liens (ou au moins les liens là-bas) en synchronisation automatiquement?
Dans prisme ( compositewpf.codeplex.com/release/... ) est un liant de projet. Vue d'ensemble ici: global-webnet.net/blogengine/post/2009/01/10/...
Super - j'attendrai d'autres réponses, le cas échéant. Pour l'instant, il semble que c'est la meilleure option que j'ai ...
Je pense que ce que vous devez faire, c'est le niveau de la taille correctement. Votre code Silverlight ne devrait être que pour l'interface utilisateur et la communication avec les services Backend WCF. Ces services dirigeraient votre code .NET 3.5 (le code que vous souhaitez partager). De cette façon, vous avez également le partage et le n-niveau.
Si vous faites un calcul lourd sur le côté client dans votre code Silverlight, puis envisagez-le sur le serveur (et probablement le dB), je pense que vous ouvrez un trou de sécurité.
Vous n'avez pas donné de raison convaincante pourquoi un projet séparé aurait besoin d'accéder au code dans le projet Silverlight.
Je suis conscient de l'architecture des applications Silverlight \ Ria et je pose la question parce que je sais exactement ce dont j'ai besoin. Donc, le conseil est bon en général, mais cela ne contient pas du tout.
Il peut y avoir beaucoup de raisons de faire des calculs lourds sur les clients - par exemple. Imaginez que j'aimerais trier certaines données (disons, 1 Mo) localement. Je l'ai déjà livré au client et le coût de son tri est beaucoup plus petit que le coût des données triées directement à partir du serveur.
C'est juste un exemple. Un autre est le programme de peinture.net. Beaucoup d'effets de filtrage doivent simplement être traités localement dans ce cas. P.s. Ne me parlez pas de Silverlight 3.0 bitmaps et d'accélération GPU, je suis conscient de cela. En bref, j'ai besoin d'une réponse exacte.
Le MSDN contient des informations détaillées sur la plate-forme multi-ciblage: Multi-ciblage sur MSDN
La question n'est pas claire. Voulez-vous créer un assemblage, puis utiliser les méthodes de cette assemblée, etc. dans une application Silverlight? Étant donné que la plupart de vos travaux réels de Silverlight se font par communication avec WebServices, je ne suis pas sûr que vous ayez un problème. Peut-être que vous avez un problème de niveaux? Ce qui signifie que vous avez des niveaux qui n'ont pas de définitions claires entre eux.
Silverlight est .NET 3.5. Je crois que tu veux dire Silverlight et WPF. En outre, il est très similaire à cette question: Stackoverflow.com/questions/208123/...
Silverlight est .NET 3.5? Semble impossible, car comme vous venez de dire, ses projets font référence à différents MSCORLIB. De plus, c'est une plate-forme d'exécution complètement différente ...
"Voulez-vous créer un assemblage, puis utiliser les méthodes de cette assemblée, etc. dans une application Silverlight" - Oui, exactement. Imaginons que je veux partager par exemple. Le même code BLL \ DAL entre l'application .NET et Silverlight.
"Je crois que tu veux dire Silverlight et WPF" - Non, je ne veux pas dire WPF. Je ne suis intéressé à aucun code de présentation du tout. Je parle de code logique seulement.
Supposons donc que je souhaite construire un assemblage contenant une classe de calculatrice avec un seul objet de calcul d'objet (expression de chaîne) et je dois construire 2 versions de cet ensemble: une pour .NET 3.5 et une autre - pour Silverlight.