J'ai donc deux fonctions et j'ai un problème intéressant. Essentiellement, je vis de rendre mon code plus portable dans un fichier CS facilement inclus.
Voici ledit fichier CS: voici la page qui le fait référence: L'erreur que je reçois est celle indiquée ci-dessus, à savoir: Message d'erreur du compilateur: CS0120: Une référence d'objet est requise pour le champ non statique, la méthode ou la propriété 'system.web.ui.page.server.get'
sur la ligne suivante: ligne 5: chemin de chaîne = serveur.mappath ("./" + nom de fichier);
4 Réponses :
Vous avez 2 options: (frais générale de la création d'un ou (non testé): ou (non si une bonne option, car elle est aussi fausse d'être statique mais elle est plutôt statique pour webcontext-appels uniquement): serveur est uniquement disponible pour les instances de system.web.ui.page -implementations (comme une propriété d'instance).
system.web.ui.htmlcontrols.htmlgenericcontrol )
Le op est sous-classement system.web.ui.page . Ce n'est pas le problème de l'OP.
que est le problème de l'OP - il n'est pas capable de différer entre la propriété statique et des instances! ... J'ai clairement indiqué instance de ...
Bien sûr, votre réponse est maintenant plus claire. Votre réponse initiale impliquée que l'OP n'utilisait pas cette classe.
Elle. Ne supposons pas, allons-nous? Sachez ce que les gens disent quand vous faites cela = p. Cela a fonctionné cependant - merci!
@ user798080 sry ... changerait cela, s'il y a toujours un bouton d'édition ... Je ne veux pas sembler arrogant, mais ... j'ai couru dans cette question seul, alors je n'avais clairement aucun doute " Bout aperçu le vrai problème ici (BTW J'espère que mon commentaire n'a pas de touche impolie - mais je crains que ce n'était ... ce n'était pas sur l'intention du tout!) Heureux que ma réponse vous a aidé!
public static string includer(string filename)
{
string content = System.IO.File.ReadAllText(filename);
return content;
}
includer(Server.MapPath("./" + filename));
Qu'en est-il d'utiliser Décrit ici: httpcontext.Current accessible aux classes statiques httpcontext.current ? Je pense que vous pouvez utiliser cela pour obtenir une référence à serveur dans une fonction statique.
J'ai couru dans une chose similaire de temps de retour - mettre simplement vous ne pouvez pas tirer le serveur.mappath () à partir du code de code .CS-derrière dans une méthode statique (à moins que ce code derrière en quelque sorte hérite d'une classe de page Web, qui n'est probablement pas autorisé de toute façon).
My Simple Correction était d'avoir le code derrière la méthode capturer le chemin comme un argument, la page Web appelante exécute la méthode avec serveur.mappath pendant l'appel. p>
code derrière (.CS): p> méthode Web-page (.aspx) Call: p>
...
doStuff(Server.MapPath("./log/"),"saveBasic");
...
De loin les plus faciles! Vous pouvez mettre toutes sortes de choses confidentielles dans le CS, en passant par la commande MAPPATH ne donnera aucune information secrète.
Je vous recommande vivement de ne pas répéter les erreurs de php. Au lieu de cela, examinez-vous dans la manière dont les principales pages fonctionnent ou passent simplement à MVC.
Nous ne sommes pas tous de voir le style de codage de PHP comme des erreurs. Pour ceux d'entre nous avec un arrière-plan de codage plus traditionnel qui nous donne des contrôles plus bas de niveau et une flexibilité de codage à la charge de la vitesse de production (bien que pas d'exécution) ou une concentration fortement-objet, elle se sente vraiment un peu plus à la maison. En outre, la documentation est meilleure = p. En outre, je trouve le plus profond que vous allez dans le trou de lapin ASP.NET, le pire que votre HTML et Javascript tendent à finir par être (car cela commence à devenir fortement généré). XHTML, JSlint, etc. est important pour moi, alors je préfère garder autant de code qui le dépend aussi possible.
Il n'y a rien de mal à la manière officielle de Microsoft sanctionnée. Cependant, pour dire qu'il est intrinsèquement meilleur parce que c'est ce que les gens vous disent de faire, c'est un peu démessionnaire car il crée souvent du code avec une empreinte de mémoire plus grande, plus de lieux pour des trous de sécurité commune, et de nombreuses autres lignes de code. Bien sûr, d'autre part, il est également préférable de grandir à bien des égards pour de nombreux lieux de travail de production avec de nombreux programmeurs individuels travaillant ensemble. Différents styles de codage, c'est tout. Je serai toujours dans le camp php, je crains.
(En outre, le C # moderne aura toujours cet obstacle d'IIS comme un moyen de dissuasion pour que je puisse utiliser sérieusement. Mod_MONO peut vous procurer un support de base décent, mais si vous souhaitez effectuer quelque chose de complexe efficacement, vous devez utiliser une autre langue pour les non-Windows / non. -Is serveurs)
@ user798080 Je suggère d'explorer la famille .net un peu plus ... Ce n'est pas principalement à propos de ASP.NET. WCF, WPF (et la bien-aimée Silverlight) et bien sûr de la console et des applications de service (et quel que soit l'autre composant que vous puissiez utiliser avec .NET) sont une autre partie. L'avantage principal de l'utilisation .NET (et le codage dans un style indépendant des composants) vous donne le plus grand plus-plus de Code partage et réaction - et c'est le problème principal que tous les grands joueurs sont après! Comme vous obtenez une compréhension plus profonde de .net, vous comprendrez ce que chrislidifiez vraiment vraiment
@Chrisllively Je pense aussi, que suggérant des Masterpages ou ASP.NET MVC est un peu comme craquer une noix avec un slagedame. Mais vous avez nommé le problème principal: MVC ... Vous pouvez toujours aller pour le modèle MVC-Modèle avec ASP.NET WebForms (même s'il est de manière limitée) - Et c'est ce que je suggérerais ici!
@Andreasniedermair: Vous avez raison, j'aurais probablement dû rester dans une meilleure explication de mon commentaire. Cependant, on dirait que vous l'avez couvert;) Merci. Pour l'OP: chaque technologie a ses propres idiosyncrasies et pratiques générales. En greffant une manière (PHP) sur un autre (Divers: WebForms, MVC, etc. En outre, vous perdez autant de l'écologie de la plate-forme que vous travaillez. Quoi qu'il en soit, votre mention de plus grande empreinte, des trous de sécurité, etc. autour de C # n'est pas précis.