Image.FromStream(PostedFile.InputStream) Échoue. (Paramètre n'est pas valide.) (AsyncFileUpload))
Je suis en utilisant un AsyncFileUpload (AJAX Toolkit) pour télécharger des images.
J'ai un Bouton sur lequel gérer le redimensionnement d'image.
Cela a fonctionné pendant un certain temps, mais pas plus...
protected void BtnUploadImage_Click(object sender, EventArgs e)
{
var imageFileNameRegEx = new Regex(@"(.*?)\.(jpg|jpeg|png|gif)$",
RegexOptions.IgnoreCase);
if (!AsyncFileUpload1.HasFile ||
!imageFileNameRegEx.IsMatch(AsyncFileUpload1.FileName))
{
AsyncFileUpload1.FailedValidation = true;
ErrorLabel.Visible = true;
return;
}
ErrorLabel.Visible = false;
var file = AsyncFileUpload1.PostedFile.InputStream;
var img = Image.FromStream(file, false, false);
...
}
Une autre chose que je trouve bizarre: Si je cherche une image qui est plus petit que 80 ko il fonctionne..!
Nous avons essayé de redémarrer le serveur, mais pas de changement.
Code fonctionne très bien sur ma machine. (entendu cela avant ?? 🙂 )
J'ai aussi essayé d'enregistrer le fichier sur le serveur, puis pour obtenir le fichier creux de l'Image.FromFile(), mais puis-je obtenir "Ne peut pas accéder à un fichier fermé."
Comment résoudre ce problème ?
Je pense que tout ajout de la fin attelle à la fonction qui est mauvais, il ne peut pas s'arrêter là, le
img
variable n'est pas utilisée.Ne pense pas que le reste est une question pertinente, ce qui se passe après l'Image.FromStream() ne s'exécute de toute façon.
Basé sur votre idée que < 80 ko de travaux est conforme à mes propres conclusions lorsque l'on travaille avec téléchargement-les ruisseaux et les
Graphics
/Bitmap
etc. Le même problème se produit dans le sens inverse, lorsque vous essayez d'écrire un Graphique à une Réponse.Hors de flux.Le
Cannot access a closed file
erreur est bizarre, mais si vous regardez à travers votre code réel, vous pouvez voir les endroits où vous ne fonctionnent pas correctement avec IDisposable
et using
blocs. C'est généralement la cause de ressources qui sont encore en usage ou qui ne peut pas être lu ou écrit.OriginalL'auteur Thomas Sandberg | 2009-10-23
Vous devez vous connecter pour publier un commentaire.
Je voudrais assurez-vous que le flux est positionné au début:
Deuxième chose à vérifier: le
requestLengthDiskThreshold
réglage. À moins d'indication à ce paramètre a une valeur par défaut de ... oui, 80 KO.Remarque: de l'omi, il devrait y avoir aucune différence si vous utiliser l'Image pour lire le fichier stream directement ou si vous utilisez un intermédiaire MemoryStream (autre que le fait que, dans ce dernier cas, vous avez réellement charge la totalité du fichier en mémoire deux fois). De toute façon le fichier original stream sera lu à partir de, ce flux de position, numéro de CAS des droits, des autorisations de fichier, etc s'applique toujours.
Note2: et oui, par tous les moyens de faire en sorte que ces ressources soient éliminés correctement 🙂
comment y parvenir sans l'aide d'ajax toolkit
atteindre quoi? vous devez être plus précis ici, ma réponse ne s'applique pas uniquement aux points d'ATK. Êtes-vous demander à propos de de téléchargement d'images en général? Si oui, regardez pour les QAs ici, ou poser une nouvelle question.
OriginalL'auteur Peter Lillevold
C'est correct, il ne fonctionnera pas. Le problème, c'est que vous êtes de passage à une gestion/non géré limite, j'ai récemment rencontré le même. D'autres problèmes sont que le flux n'est pas directement là-bas et de l'Image.FromStream n'a aucune idée de la façon de traiter avec elle.
La solution est assez simple: tout lire PostedFile dans un MemoryStream (il suffit d'utiliser
new MemoryStream()
) et l'utilisation MemoryStream avec leImage.FromStream
. Cela permettra de résoudre votre problème.Assurez-vous de faire bon usage de
using
lorsque vous travaillez avec desImage
,Graphics
etStream
s. L'ensemble de la mise en oeuvre de la IDisposable et dans un ASP.NET de l'environnement, en n'utilisant pasusing
blocs correctement, peut et va entraîner une augmentation de l'utilisation de la mémoire et de l'autre côté méchant effet sur le long terme (et ASP.NET les applications fonctionnent très longtemps!!!).La solution devrait ressembler à quelque chose comme ceci:
Mise à jour: la traversée géré la question des limites se produit uniquement dans le sens inverse (à l'aide de flux de Réponse), il me semble, pas à Télécharger des cours d'eau, mais je ne suis pas entièrement sûr.
Remarque: il n'est pas garanti que la
Read
œuvres. Si non, la valeur de retour contient le nombre d'octets effectivement lus. Vous pouvez rendre votre code plus robuste par de toujours vérifier la valeur de retour deRead()
, ou en boucle jusqu'à ce que tous les octets sont lus.Essayé ceci: chaîne imageID; using (var mStream = new MemoryStream()) { var uploadStream = AsyncFileUpload1.PostedFile.InputStream; var = new byte[uploadStream.Longueur]; uploadStream.Lire(tous, 0, (int) uploadStream.La longueur); mStream.Écrire(tous, 0, (int) uploadStream.La longueur); mStream.Seek(0, SeekOrigin.Commencer); using (var img = Image.FromStream(mStream)) { imageID = ImageCreation.SaveImage(img, true); } } Mais je get {"Paramètre n'est pas valide."}, toujours sur l'Image.FromStream. (Maintenant, même sur la machine locale)
ensuite, je crains que vous aurez à faire un peu de débogage. Placez un point d'arrêt et de passer par le code ligne par ligne. Je soupçonne que le flux n'est pas complet pour une raison quelconque, mais je ne semble pas être en mesure de créer la même situation... MemoryStream comme intermédiaire de flux toujours travaillé pour moi.
Ok, je vais essayer ça. Btw: Les octets individuels dans "tous" ont été "0". Est-ce à donner des indices?
OriginalL'auteur Abel